While I was preparing for my interview with Bruce Eckel, a quote appeared in his Web log in May that said "If it's not tested, it's broken." It got me thinking about how much I actually tested the code that I wrote. Now I don't write JUnit tests for everything, but perhaps I should. To that end, here's my proposal (I'm looking forward to the royalty check):
1.   Sun should embrace the JUnit framework and include it in the Java Development Kit.
2.   Any untested methods should throw an UntestedMethodException.

If that doesn't tell you how much that download has been tested, I don't know what will. Now I appreciate that there will be developer overheads in creating test cases, but perhaps it may make the job title "Test Engineer" popular again. This will decrease the number of unemployed IT staff; everyone's happy - apart from developers.

It's time to face facts, ladies and gentlemen; we got away with it for far too long. Now it's time to change. Let me first reassure you that "change" is not a dirty word; in fact it's one of the best things that can happen to you. Thinking differently forces you to apply yourself differently; take note of the implications of that change, and create a more secure, tight, and successful way of working. You feel good, the team feels good, and then management sees it and they feel good; company profits go up, the board and the shareholders feel good. All that from one small change. Only you control your destiny so make it work for you. Insist on change.

Anyway, back to testing. The time has come to put our former ways of testing behind us and look properly at what we do. Take the following example:

public class Calc {
public Calc(){}
public add(int a, int b){
return a+b;
}
public subtract(int a, int b){
return a-b;
}
public static void main(String[] args){
Calc c = new Calc();
System.out.println(c.add(1,2));
System.out.println(c.subtract(5,2));
// ooh! It works :)
}
}

It's very easy to assume that this class has been tested and what I've been guilty of (I can only assume countless others as well; I just hope someone else confesses :-) ) is accepting in my mind that it's okay. What we really should be doing is supplying proof to everyone else that it works! I don't want JUnit tests to be optional; I want them to be mandatory! Eclipse does a nice job of creating unit tests, but it would be nice if Eclipse (or insert the IDE of your choice) could monitor the methods and create unit tests for them automatically. Then all you'd have to do is create some test data and run the tests. Easy, simple, and you'd have evidence.

It's all too easy to fall into the trap of delivering code that you think is okay, but in no time at all management is at your desk demanding to know why the application is not working. What evidence do you have with no unit tests? Effectively none. Now I openly admit that I have sat on the fence for far too long concerning this, and I think it's one of the reasons that management spits fire and loathes some IT departments. At the end of the day there is only one person who can change my predicament - me.

Let's put down our lattes/smoothies/stock options and start writing some proper unit tests, with decent test data and proper outcomes. I'm fed up with the stigma. If you want more info on JUnit, have a look at www.junit.org. There's also an article in JDJ called "Test First, Code Later" by Thomas Hammell and Robert Nettleton (Vol. 7, issue 2) that's excellent as well.