Originally posted by Junilu Lacar:
Since you mentioned that you were using the TDD approach throughout the book, I was wondering more on the lines of whether there were any new idioms related to doing TDD to develop code that used new features in Java 5.0. Say for example, I wanted to write a class that had methods that used generics; are there any differences in how I would do TDD for this class? Or say annotations. Is there a way to test-drive annotations?
Greetings Junilu,
Sorry I didn't answer that better. To directly answer your last question, yes, you can test-drive annotations. I include a half-chapter worth about annotations, in which you incrementally develop your own simple testing tool (like
JUnit but without a GUI). As far as idioms, I'm not sure I'd call this an idiom, but the way you test annotations is to provide dummy classes with methods or other elements that you annotate. The easiest way is to supply an additional package-level class that does nothing; I put it directly in the same source as the test class itself.
Here's a bit of paraphrased test code that demonstrates this:
(Note that there's some bootstrapping necessary here...)
In other words, I supply the class SingleMethodTest solely for the purpose of demonstrating the @TestMethod annotation. One might call this a mock. I won't, since the term "mock" carries specific connotations for certain people. The benefit of using such dummy classes, as opposed to classes actually in your system, is that they are stable, since they're only used by the test.
For testing parameterized types, the way you approach testing their functionality doesn't change. What does change is that you need to ensure that the behavior isn't adversely impacted when you change what you bind the parameterized type to. Other than trying to test at least two possibilities for each bind parameter, I haven't developed an idiom here.
In general, the new language features in 5.0 don't alter your fundamental approaches to testing: decide how you want things to work from a client perspective, and then figure out how you're going to prove that things actually worked that way. Since Agile Java goes through all the new language features, you'll see one or more ways to approach testing each of them.
Regards,
Jeff