Test-driven development (TDD)

Why TDD The point of TDD is to drive out the functionality the software actually needs, rather than what the programmer thinks it probably ought to have. The way it does this seems at first counterintuitive, if not downright silly, but it not only makes sense, it also quickly becomes a natural and elegant way to develop software.

Start with the test We start by writing some client code as though the code we want to develop already existed and had been written purely to make our life as easy as it could possibly be. This is a tremendously liberating thing to do: by writing a model client for our code, in the form of a test, we can define programmatically the most suitable API for our needs. In addition, we assert the behavior we want.

The test fails The next stage is to write the minimum amount of code to get the test compiling. That's all, just a clean compile, so you can run the test (which at this stage will fail).

Write only enough Now, and only now, you write the application code to satisfy the test. The final piece of the puzzle is to refactor the code so it's as simple as it can be. This then becomes your development rhythm: write a test, write some code, refactor.

Test – then Code Writing the test before you write the code focuses the mind - and the development process - on delivering only what is absolutely necessary. In the large, this means that the system you develop does exactly what it needs to do and no more. This in turn means that it is easy to modify to make it do more things in the future as they are driven out by more tests.

Guidelines for test first design The name of the test should describe the requirement of the code Only write the simplest possible code to get the test to pass, if you know this code to be incomplete, write another test that demonstrates what else the code needs to do If a test seems too large, see if you can break it down into smaller tests If you seem to be writing a lot of code for one little test, see if there are other related tests you could write first, that would not require as much code Test the goal of the code, not the implementation One test/code/simplify cycle at a time. Do not write a bunch of tests, and try to get them working all at once Keep writing tests that could show if your code is broken, until you run out of things that could possibly break

Guidelines (cont) If you are unsure about a piece of code, add a test you think might break it A test is one specific case, for which there is a known answer If all of the tests succeed, but the program doesn't work, add a test Tests should be as small as possible, before testing a requirement that depends on multiple things working, write a test for each thing it depends Tests should not take longer than a day to get working, typical test/code/simplify cycles take around 10 minutes Do not fix a bug until you have written a test that demonstrates the bug

JUnit.org JUnit is an open source Java testing framework used to write and run repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks. JUnit features include: Assertions for testing expected results Test fixtures for sharing common test data Test suites for easily organizing and running tests Graphical and textual test runners The official JUnit home page is http://junit.org.

The goal

Installation of JUnit Below are the installation steps for installing JUnit: unzip the junit.zip file add junit.jar to the CLASSPATH. For example: set classpath=%classpath%;INSTALL_DIR\junit3\junit.jar test the installation by using either the batch or the graphical TestRunner tool to run the tests that come with this release. All the tests should pass OK. Notice: that the tests are not contained in the junit.jar but in the installation directory directly. Therefore make sure that the installation directory is on the class path for the batch TestRunner type:     java junit.textui.TestRunner junit.samples.AllTests for the graphical TestRunner type:     java junit.awtui.TestRunner junit.samples.AllTests for the Swing based graphical TestRunner type:     java junit.swingui.TestRunner junit.samples.AllTests Important: don't install the junit.jar into the extension directory of your JDK installation. If you do so the test class on the files system will not be found.

How do you write testing code? Create an instance of TestCase: Create a constructor which accepts a String as a parameter and passes it to the superclass. Override the method runTest() When you want to check a value, call assertTrue() and pass a boolean that is true if the test succeeds

More Information Test Driven.Com JUnit CookBook JUnit Test Infected: Programmers Love Writing Tests From the JUnit site Frequently asked questions