I have been a long-time fan of annotations, and my devotion started with
EJBGen (which was using JavaDoc annotations in 2001, imagine that!), followed by
my involvement in JSR 175 and now, with TestNG.

Annotations make a lot of sense for a testing framework, but once in a while,
I still hear a few people wondering if they are appropriate for this particular
domain.  Not only do I have a few reasons to believe this, but
interestingly, the latest emergence of something called Behavior-Driven Testing
is making this point further.  Here’s why.

JUnit requires your test methods to start with the word "test". 
When you do this, you are actually adding information to
your method, attaching the "metadata" (extra information) that it’s not just a
Java method:  it’s a Java test method.  This is
the very definition of "metadata":  data on top of existing data.  But what are you really trying to achieve?  You are flagging your method
so that it can be found by JUnit.  If you think a little bit about it, this
goal doesn’t have much to do with the name of your method.

Here is another way of looking at it:  what if you are using a framework
that, says, automatically generates RMI stubs for any methods that start with
"remote".  How do you combine this with JUnit?  It’s easy to see that
this approach doesn’t scale very far.

Recently, a practice called Behavior-Driven Testing (BDT) has received some
publicity.  The idea is to use a different terminology for your tests, not
only for your test method names, but also in the way you perform your
assertions.  Here is an example:

public void testAccountIsEmpty() {
  assertEquals(m_account.size(), 0);

Which can be rewritten as:

public void accountShouldBeEmpty() {
  m_account.shouldEqual(0);

I’ll save the discussion on the pros and cons of BDT for a future posting and
observe that the idea of baking the "test" attribute into the method name breaks
down for this approach, proving the point that the name of the method and what
this method means to a particular framework are completely orthogonal ideas.

Of course, the corollary of this observation is that
TestNG already supports BDT :-)