Software development can sometimes appear overwhelming. A complex project might have to interact with vast databases, co-operate with external dependencies - such as online banking software - and work seamlessly for users who potentially know very little about your business. As developers, we work really hard behind the scenes to make sure all these moving parts are co-operating and running smoothly. One significant way we achieve this is by using a process called test driven development.
Traditionally, developers would work by directly writing production code (the bricks and mortar that make up any piece of software). As they develop, they manually start up the application and check it’s working as expected. There is a logic to this but also a fundamental problem: this manual testing takes time. As the project grows, it takes more and more time to compile and run the code, and the developer ends up with a slow feedback cycle. To counteract this, developers have adopted a new process called test driven development. This changes the fundamental way we approach writing code and ultimately produces a far more robust final product.
The key to to test driven development is that instead of immediately writing production code, we begin by writing a piece of test code, which will automatically run the production code and check that it works as expected. Since we haven’t written any production code yet, we know this test code won’t work - indeed it’s not supposed to! However, writing code in this way forces us to take a moment to think about exactly how our production code will need to look. It’s a counter intuitive idea, but one that makes sense when you understand the rest of the three-step process, which in its purest form goes something like this.
- Begin by writing test code to test the functionality you’re going to implement. It fails but shows you what is and what isn’t going to work.
- Use these results to write a piece of production code, sufficient to make the test code succeed. Repeat these two steps until you’ve implemented the feature you’re developing.
- At this point it’s time to ‘refactor’ your code. This is the refining stage: taking the potentially messy code you’ve started out with, and tidying it up to make it more readable and maintainable.
This iteration process is intended to be quick and we often think of it like fast food: small rapidly produced chunks in a larger meal. By driving the entire coding process through testing we create an immediate feedback loop that quickly gives us confidence that our code is working. This approach may initially seem slower than just writing production code only, but this rapid feedback cycle really pays off due to the ability to quickly iterate as you develop, letting you pick up the pace and ultimately save time and money.
There are other benefits for clients. By forcing us to continually test tiny elements our focus on the small detail is greater and there is far less chance we’ll miss those baffling bugs that don’t show up until a user does something unexpected. For example, if somebody inputs too many characters into a text box, how will the system respond? It might be fine, but it could cause the entire thing to fall over. If you haven’t thought about it during testing, there is a chance nobody else will either and the fault could find its way through to launch. At this stage a member of the public might become frustrated with your software and fire off a complaint, and the blame for that ultimately lies with the developer.
Test driven development isn’t really something clients have to think about – it is a method of working rather than a coding language with cost implications or affecting overall functionality. But it should give you confidence that your product will work the way you want it to, with as few problems as possible.
