I’ve been asked about TDD and BDD by a few people over the last couple of weeks, so I thought I’d post a couple of summaries and some useful links. Let’s start with TDD.
Test-Driven Development (TDD) is a development approach, not testing as many think of it. As Dan Ashby says, “TDD is actually a really poorly termed approach. It’s not actually “testing” (in the sense of testing being investigatory); it’s actually a process that forces feature refinement and lateral thinking up front of the feature being developed… it is actually all about design.”
This is how it works:
- Developer makes sure they understand the requirement they are being asked to implement (i.e. the feature or improvement). What behaviour does the person asking for the requirement want once the feature/improvement has been completed?
- Developer writes an automated test case to see if the requirement is being satisfied. Initially, the test should fail as no code has yet been written; if it doesn’t, then either the test is wrong or the requirement is already being satisfied
- Developer writes just enough code to get the test to pass
- Test runs and passes
- Developer refactors code to tidy code and fix any problems (making sure that the test doesn’t start to fail)
- Move on to next request and return to step one
A great example of TDD tests can be found on Viktor Farcic’s blog.
TDD maximises the benefits of incremental iterative cycles. Every step should be small to encourage a fast pace and frequent delivery.
One of the major benefits of TDD is that the tests that are written for each feature remain and continue to be run against future code that is written. So, if code written in the future breaks something you built months ago, you know about it. In addition, it acts as “living documentation” of your code.
However, as James Shore states, “TDD is difficult to use on legacy codebases. Even with green-field systems, it takes a few months of steady use to overcome the learning curve.”
In summary
TDD is a technical development approach that focuses on the end result. You set tests upfront, then work towards satisfying them. It forces you to consider what outcomes you want before you start development. This might sound obvious, but it often doesn’t happen in the depth that is necessary.
Please note: I’m not an expert in TDD but have worked with people who know what they’re talking about so I’ve asked them to help. Thanks to Kikyoung Kwon, Paul Bassan and Dan Ashby.
Image (homepage): Kerem Yucel
An interesting article but there are a few points I’d like to comment on TDD is a developer activity so having a tester comment on it especially Dan who is quite opposed to automated tests isn’t very objective. To say it’s not testing is insulting to developers as it requires a fair degree of thought and investigation, sure it encourages better design but the benefits of these “Tests” (yes this is what they’re called) is substantial as hundreds can be run in seconds.