When reading articles and visiting clients I often hear Test Driven Development and Behaviour Driven Development mentioned but for the wrong reasons.
In my opinion a client needs to do both. Both overlap but are essentially different. We need BDD to focus on understanding key concepts that will ultimately result in a design. BDD helps clarify the requirements in terms of understanding behaviour. If its not specified anywhere then we have to hunt. TDD also helps to clarify requirements from the Test perspective.
Without any functionality built we should be in a position to verify that the target platform works and at least meets the non funcitonal requirements. This is generally a missed opportunity and generally done too late or not at all in a project. Why bother? Because during the project duration some essential components will change and we have to verify the impact. Think upgrading to a new version of Java or JBoss that can have a significant impact on how an application will perform. Deploying into different environments usually involves different individuals and organisations, think: development, integration, functional test, performance test, staging, production.
Each environment has a different configuration and we need to constantly verify that these have first been setup correctly and second that they remain setup correctly. This focus emphasizes the need for TDD to ensure that we have no surprises and more importantly risk reduction.
What stops us changing essential components is not the amount of work for the developer but rather the long testing cycles, not just functional also non-functional. In order to bring the length of a test cycle down we need to implement TDD that can be executed automatically avoiding manual intervention.
To conclude, testing, or let us call if verification, must begin from day 1 and the execution of tests needs to be as invasive as possible producing rapid feedback.
