Martin Fowler also discusses the importance of testing -- early and often -- as he describes "Continuous Integration". (See his article at http://www.martinfowler.com/articles/continuousIntegration.html)

At IronGrid, we've embraced that concept as well and followed on specifically with "Continuous Performance" which focuses on (you guessed it) performance testing at every build -- early and often. Check the whitepaper "Continuous Performance: The Next Advance in Software Development" at www.irongrid.com.

Bill, I completely agree with what you say... The source code example does show the point I was trying to get across, that people are willing to use a main() method as a valid testing case. This is seriously wrong.

public class Calc {
public Calc() {
}

public int add( int a, int b ) {
return a + b;
}

public int subtract( int a, int b ) {
return a - b;
}

public static void main( String[] args ) {
Calc c = new Calc();
System.out.println( c.add( 2000000000, 2000000000 ) );
System.out.println( c.subtract( 5, 2 ) );
// ooh! It works :)

// -294967296
// 3
// oops! It doesn't work :( The code you don't write has the fewest bugs.
// If you depend on tests, write dependable tests.
}
}

I loved the article! I just recently graduated from college. I am very lucky to have a boss-(technical teacher) to take me under his wing, and show me the way to develop software. Everything begins with the test, or atleast it should. Writing the software is easy, making it work is the hard part. But, if you test the code before you write it, then putting it together ensures the stability of the code. It also helps save time in the development process. If a programmer can test his/her code first, then this will save them time debugging their code later. I use Netbeans JUnit IDE to write and test my code. I write out a class with empty methods and create JUnit tests from them. the JUnit methods are all set to a failed state, until you write your code for the method. It is somewhat of the same format as the unTestedMethod format used in the article.

I think it is right that the secret to testing is adopting the right mind set. I agree with Kent Beck and others that the best way to write test code is to write the test before the code you are going to test. This might sound crazy at first but it makes alot of sense. First it makes you more honest. If you've already written and compiled code you tend to lose interest. The fun bit of working out how to do it and making it compile and run is over. Writing a test is boring after that. Writing the test first is just as challenging as writing the code itself though and you can be honest and imaginative thinking up test cases because you haven't invested any time or pride in what you are testing yet. Also you tend to design code to be more reusable. Usually when you design a class you have a particular client and use case in mind - it's hard to keep the interface general with that requirement in mind. But your test provides another client and another use case, forcing you to think more generally about the class you are writing. On the whole I've found this shift towards test first code has improved my productivity and the quality of my work considerably.

It is nice to here that a developer dose admits to not testing enough. As a QA engineer that has seen development think that test all of their code, and does not need QA, this is good. With industry laying off most of their QA engineers in order to get the product out early. If they would have QA start at the specification level their product would get out the door sooner.