Filippo Diotalevi wrote about a wishlist for a better JUnit and he mentioned Cedric’s pet idea of using annotations to identify test cases.
I’ve tossed this idea around a few times, and I’m still not sure what benefit a developer is going to have from using annotations. See this, for example:
@test public void testDoSomething() { ... }
Does the annotation really give me value? Okay, I can drop the test prefix, but that’s not much, really.
Using annotations to identify test classes, I can see a bit; from the point-of-view of a TestRunner, finding classes with a particular annotation is probably easier than finding classes that have a naming pattern or descend from TestCase. But still, this is a problem that has already been solved.
I would like some annotation support, however. Here’s my wish list. 🙂
- declaring set-up and tear-down methods, for a given test method, in addition to the standard setUp() and tearDown() that already exists.
- customising the TestSuite that gets created (if you don’t have a suite() method already); in particular, creating a suite-level setup and tear down is handy.
- Decorating particular test methods. For example, to indicate that an exception is expected (similar functionality to ExceptionTestCase)
The theme here, BTW, isn’t to replace functionality that already exists via the reflection support just for the sake of using annotations, but to provide new features that didn’t exist before. This, in turn, may drive a need to replace the reflection support with annotations, but in that case it would be as a stepping stone to greater benefit.