Test Driven Development

Introduction

Our aim is to explore the philosophy of TDD.  The concept and practice of writing tests first and then developing a system from the inputs to the tests and the results from the tests is awesome but I won't call it revolutionary.  I will explain why once we've got the concepts under our belts.

History

When I was studying for my degree I can clearly remember the tutor at the time introducing the concepts of Jackson diagrams and DFDs.  During the course of learning these techniques the tutor addressed the idea of specifying a system like this

The idea was really simple.  Workout the input values, specify the expected output values, and functionally decompose the process element using Jackson type elements.  Today we've replaced the phrase "functionally decompose" with the phrase "refactor".

Look, I don't want you to get it into your head that I'm pushing for us to go back to structured techniques.  I've been an OO developer since 1989 when Borland release its first C++ compiler, Turbo C++.  What I am showing you is that the concept of test first, code second isn't new.

What is different is the incremental iterative approach to building out the landscape.  Also, in the structured model, you would attempt to define all the input and output values before any coding could be done.  Not so with TDD.  Instead, everything is done incrementally and iteratively.  Even the identification of the tests.

Should I care about testing

Now if you're reading this then I'm assuming you have an interest in unit testing and delivering quality systems.  Why have I used the term system and not software?  It's because the principle of TDD can be applied to the development of software and infrastructure.  But can we apply to the concepts of design and architecture?  That's a little more complex as these artifacts are logical constructs that cannot be executed.  Your architecture and designs are made manifest through your software and hardware.