IndicThreads >> JTiger makes extensive use of the new J2SE 5.0 annotations. What are the advantages of going with annotations as compared to earlier ways of writing test cases?

Tony Morris >> Annotations provide the ability to specify metadata on Java language constructs and be able to retain that metadata information at runtime and look it up using reflection. This is in contrast to what existed prior to annotations, which was typically the specification of metadata as mere javadoc comments, which of course, is lost at compile-time.

It will also hopefully prevent the common misuse of interfaces as metadata; specifically, declaring interfaces without methods (aka tagging or marker interfaces) since interfaces are best used for interfacing to a system, not for specification of metadata. Declaration of an interface without methods and without inheriting from two or more interfaces is a horrible practice.

"JTiger takes advantage of the annotation language construct...."

JTiger takes advantage of the annotation language construct by permitting the developer to specify metadata on their unit tests and that metadata will appear in test reports or allow the developer/tester to alter the way in which the unit test is executed.

IndicThreads >> What are your thoughts on test driven development (TDD)? Do you recommend using the TDD approach to anyone planning to start using JTiger?

Tony Morris >> I think Test Driven Development is an excellent basis for discovering correct software development processes. I think that by completely understanding the reasoning behind TDD allows a developer to make variations to suit their specific needs in a given context. As a part-time university lecturer, I wish these types of topics were taught (properly) in tertiary institutions so that the next batch of new developers will be able to bring some refreshing perspectives to the industry.

"Test Driven Development is an excellent basis for discovering correct software development processes...."

I prefer to describe the fundamental basis of correctness by using requirement analysis techniques, which TDD inadvertently encourages. A trivial example is my preference to view unit tests as actual software requirement specifications, since the developer is not actually testing anything, more so, they are specifying the requirements of their software. It is only at validation time where any testing takes place. I think its often severely under-estimated and misunderstood just how important it is to specify software requirements correctly and concisely.

"Its often severely under-estimated and misunderstood just how important
it is to specify software requirements correctly and concisely...."

I also find that code coverage tools provide an excellent learning curve for refining techniques to specify requirements. For example, most developers who have used a code coverage tool for their unit tests have found a segment of code that they were unable to execute with their unit tests. This begs the question, just what is the purpose of that piece of code if it near impossible to execute it? This kind of reasoning leads to the discovery of many common software design practices that turn out to be extremely flawed. Though admittedly, it does require some serious reflection, and mind bending objectivity and reasoning to really obtain or approach a level of clarity.

IndicThreads >> Finally, with so many unit testing frameworks now available, do you think developer reluctance to unit test code has been suitably tackled or does more need to be done?

Tony Morris >> I believe that there is a huge amount to do. I also believe that there is a horribly ill-informed critical mass of software developers that are reluctant to change their ways to reflect the major advantages that can be gained from integrating unit testing into the software development process. In my teaching, learning and communication with developers, I tend to target the naïve mind and encourage objective thinking and analysis on their behalf so as not to provide them with any of my biases and preconceptions.

"There's a huge amount to do to tackle developer reluctance to unit test code...."

 "A horribly ill-informed critical mass of software developers that are reluctant to change their ways...."

I find it very satisfying when a discovery is made by a fresh graduate that not even a claimed experienced developer could possibly understand. I think the key to discovering what needs to be done and to encourage sound development techniques, is objectivity, with less emphasis on years in industry and the ever dominant egotism. After all, the industry is relatively immature. Who knows which direction we go next? Importantly, never cease the pursuit of knowledge and learning and emerging development and unit testing techniques have the potential to rapidly increase the rate of learning. Even the most knowledgeable software developer is a mere drop of water in the ocean of knowledge. The rest will fall into place.

"Even the most knowledgeable software developer is a mere drop of water in the ocean of knowledge...."

IndicThreads >> Thanks Tony. Any final notes for our readers? Also could you share your blog url / email?

Tony Morris >> Remember that learning from the mistakes of others is cheap, and to always think for yourself. Unit testing is a fundamental process of software development since it can directly digress to requirements analysis. A software solution cannot exist without a well-stated problem, or from another perspective, a software solution cannot possibly exceed the quality of the problem statement. I dont have a blog, but my personal website is http://www.tmorris.net/ or please feel free to drop me a line at tmorris AT tmorris DOT net

Your Name / Email Address
Comment
Spam Protection - Please enter the code in the image -

Listen to code