Test Driven Development
Modular approach makes life easier for developers, and projects more robust for users.
A good project is all about the nuts-and-bolts side of their software; the cogs that make the whole thing tick. It’s the stuff that clients don’t usually see, but that provides them with clear benefits all the same. We’ve asked one of our lead developers, Phil, to help us explain how one such set of cogs can be valuable for both client and developer.
Test-Driven Development has been around since the late 90s, but it’s only in the last decade that it’s really come into its own. It’s not surprising that it’s gained momentum, as it provides big benefits: cleaner, more reliable code, quicker testing, and easier implementation of future features.
Breaking it down
TDD turns testing inside out – instead of writing software elements first, and then testing them, the test is created first, with code then being written to fit. It makes it easier to see where problems are if they arise, because you know what the test you wrote wants the code to be doing.
This approach also has benefits for how developers think about their software, Phil says. Coding in this way pushes you towards a modular structure; software developed in blocks that work together. This makes for more straightforward code, which is easier to debug and to add to later. As you optimise the code (refactoring) after each module is written, the code improves as you go.
It also, in turn, simplifies testing, as developers can spot which module is causing a problem.
The test-driven development process
Cutting the strings – removing external dependencies
Modular development is a big deal because it can reduce the problems caused by external dependencies; something outside of the software itself that it relies upon to operate properly. As an example, if a company requires new software to manage a legacy CRM database stored remotely and accessed via a web service, then the software relies on the database and web service to do its job.
If something goes wrong, it can be difficult to ascertain if the issue is within the software, or in the external factors. Because TDD encourages modular design, you would write a ‘proxy’ – a chunk of code that handles the communication between the database and the core logic of the software. The proxy handles the communication, so it’s easier to locate if the issue is with the data coming in, or a bug within the software itself.
And, of course, if the bug is within the software itself, TDD means that you’ve got cleaner code and pre-written tests to help find it.
Example of a modular system at work
So why does it matter?
“TTD simplifies future development,” says Phil, “which saves time for both us and the client if they want to expand the software later on. It’s not for every project, of course – you’ve got to know what method to use when. But for projects where TDD is the way to go, I’ve seen it simplify and improve projects at both ends of the process”.