"Red-green" testing and "movable" code

After defining the Domain and UML models, the next step is to build a test case and start testing. In case you're wondering: yes, you read correctly, we create test cases and carry out tests before we've even developed any code. That is Test-driven Development!

Test first: the unit tests – which fail, of course – show us what we have to program. We advance in small, easily comprehended, iterative cycles, testing and programming only a single function at a time. Every new test builds directly on its predecessor, extending the process while maintaining the functionality already achieved.

To do this requires test instruments: the tests must be repeatable and as far as possible automated. Such tools, or the TYPO3 Extension for Test-driven Development, enable the developer to see at a glance whether a test was successful or not: a red bar for a failed test, a green bar for a successful test. Thus we knowingly begin the cycle with a "red" Unit Test and introduce the code changes required until the red test turns green. Once this goal has been achieved, we carry out a red Unit Test for the next function – including the previous test results – once again changing the code until we get green, and so on … The tests provide a continual feedback flow, so that errors and defects can be recognized early and corrected.

After each successful Unit Test we carry out a Refactoring. This is a process whereby the program code is restructured and optimized to meet standard program guidelines and remove redundancies etc. Any functionality already tested is not affected by this. The goal is to have a simple, comprehensible and extendable code.

Finally we run a final Unit Test, to ensure that the code still behaves the same after restructuring, and that no new errors have snuck in through the back door.

Larger, integrated units of our solution are then proof-run on standard system and acceptance tests. These ensure that the components carry out the expected functions correctly, completely, cleanly and up to speed, thus fully meeting our client requirements.

Test-driven development and refactoring ideally complement one another: the Unit Tests ensure the functional quality, refactoring the structural quality of our software solution.

The above procedure has several clear advantages:

• A function is only developed when it is actually needed (just in time);
• No test cases can be overlooked;
• Only that which can be tested is programmed;
• Only that which has been tested is implemented;
• Previous functionality remains secure, in the event that the code is altered or extended.

In this way we can ensure the creation of code that is at once slim and trim, well-structured, fully tested, easily maintained and "movable" – in other words, alteration- and extension-friendly.