It seems like every week there is a new buzzword where web development is concerned and sometimes it is hard to distinguish which of these are just trends and which are here to stay. One of the most recent of these buzzwords is ‘test-driven development’. It’s the phrase that’s on every developer job spec, but what actually is it?
To understand the meaning of this, we need to understand what exactly we mean by ‘tests’.
Traditionally in web development, testing entailed loading up the finished product in a web browser and manually checking that everything works and looks as expected. Of course, this is still a valid and essential form of testing. However, as web pages have become much more complicated, this is no longer enough.
The most irritating thing is that this becomes inevitable. No matter how good the developer is, the more code that is added to the codebase, the more difficult it becomes to understand. You end up with pieces of code that rely on other pieces of code and it becomes hard to remember what code relies on what. Then, once you throw additional developers into the works, it becomes even more of a challenge. Each developer working on a single codebase has to figure out what every other developer has added and what code that relies on.
This is where writing tests can come into play. We can write a test for each specific function and when we run that test we can essentially simulate exactly what that function is supposed to do. This then acts as a live piece of documentation within the code.
A well-written test can allow a developer to see what exactly a piece of code does at a glance. Beyond this, it makes sure that piece of code functions exactly as expected. If a change has been made to it and it no longer functions as it should, the test will fail. From there, the developer would then know exactly where the problematic code is and work out what’s going wrong.
Then comes in test-driven development. The idea behind this is that the developer actually writes a test prior to writing a piece of code. The test acts as the specification for the code, this allows for complete test coverage from the get-go. Using this method, however, comes with a downside and that is the age-old dilemma of time. One of the fundamentals of test-driven development is that the test and the code are equal partners; for every function, there’s a test and this means it takes twice as long to write. On the upside, all code in the codebase is well documented and tested and time taken debugging issues further down the line can be dramatically reduced, as all developers can easily understand the code.
So, is test-driven development here to stay? I would argue that it never really, truly arrived. A lot of people claim that they practice test-driven development, however, in reality, it usually means they just write tests. As mentioned previously, writing one test for every function is essentially doubling your development time and is often not seen as a cost-effective way of working. I would, however, beg to differ. More tests equal less time spent debugging, reduces the likeliness of bugs being added and reduces time spent on someone in the know to explain code to other developers. All this time is accumulative and will eventually outweigh that time taken writing those tests in the first place. Cars have brakes so they can go fast without crashing, tests are a developer’s brakes.
If you are interested in building a new test-driven website or simply want one of our developers to give their audit on your site, then please feel free to get in touch!