Agile Java, written by Jeff Langr, walks through test-driven development with Java 5.0. It shows how to translate oral requirements into practical tests, and then shows how to use those tests. This chapter, Assertions and Annotations, shows how to build a testing tool, with full code and exercises, using Java 5's annotation facility.
- Posted by: Joseph Ottinger
- Posted on: June 13 2005 09:52 EDT
Read Agile Java: Assertions and Annotations
- Why bother with assert? by kim pepper on June 15 2005 19:11 EDT
- Chapter from Agile Java: Assertions and Annotations by Remi Forax on June 16 2005 03:54 EDT
- Building your own testing framework by Thierry Janaudy on June 16 2005 04:46 EDT
- weird @tag uses by Daniel Haran on June 16 2005 10:54 EDT
I don't see the practicality of an assert statement if they can be switched off or, more importantly, disabled by default.
I guess this chapter is more of an academic exercise rather than providing a real testing framework alternative.
I don't see the practicality of an assert statement if they can be switched off or, more importantly, disabled by default.The whole point of an assertion is that it can be switched off. That way you can run a very expensive contract-enforcement function during dev and QA and then in production, just rely on the underlying code consistency.
The development of the alternate test framework is somewhat of an academic exercise. However, if things are under your control--as they should be within most environments--there's no reason that depending upon annotations should be a problem. Particularly, in this case, you should be able to ensure that annotations are turned on for use in the testing framework.
Brain dead. Replace "annotations" with "assertions" in previous post.
I have notice a mistake about meta tag @Inherited (page 561),
@Inherited has no effect if used on target other than type.
Funny enough I just put this web site yesterday testinium.org
I like simplifying things. Building an Eclipse plug-in to parse @modified tags on each method doesn't seem to accomplish this. Don't we have version control to see who did what to a file?
Using @Override to make sure you don't mess up seems like a definite gain, but most of the examples in the sample chapter seem like fantasy.
...but most of the examples in the sample chapter seem like fantasy.Maybe. But it is the first good, real world example I've seen on how to use annotations.
I've also used annotations to enhance JUnit 3.8.1 with the @Ignore annotation (see http://langrsoft.com/articles/annotations.shtml, written in early 2004). The goal is to raise developer awareness of temporarily-bypassed tests through the JUnit GUI. I actively use the feature, so it's definitely real world.
The @Ignore annotation will be available in the forthcoming JUnit 4. Hopefully by then Agile Java will have sold enough copies to warrant a second printing with updated JUnit information. :-)