Skip to content

Test Driven Development

At the outset let me just say I am not a programmer.

At the outset let me just say I am not a programmer. Until I started working with Experience Digital I had only a basic understanding of development, let alone the various types or methodologies involved.

As I am not a developer this post not intended to teach developers about test driven development, except at the most basic level.

Rather this blog is intended as an explanation as to why Experience Digital uses test driven development; an homage to the amazing work of the development team and the dedication that they employ in every project we embark upon.

What is Test Driven Development?

I am not going to lie, when tasked with writing this blog I was worried that I wouldn’t be able to do justice to what is such an important element of what we do here. I was worried I wouldn’t be up to the task of making it sound interesting. I was worried I would be bored.

As it turns out Test Driven Development is not just interesting, it’s also a remarkably simple concept.

At a very basic level Test Driven Development is about spending time at the beginning of a project so that you minimise time at the end. It is called Test Driven because the first thing you do is write the test, rather than write the platform.

Wait… Isn’t that backward? How can you test something you haven’t even written yet?

The Test becomes the Benchmark

The concept behind Test Driven Development (or TDD as the kids are calling it) is that the test derives all possible outputs from the proposed system (or module). To pass this test the system must provide all the expected outputs.

I can hear you say “Sure, ok but isn’t that just normal?” well, yes and no. A developer not using test driven development will write the entire system, or module and then create a script which runs through their work. That’s fine if you are very careful but so are internal audits. The Developer has just written the script so they know how it is meant to operate and they can adjust the test accordingly. As a result they may not test every single function, only the primary ones. The test is not the focus, the software is.

With every single software solution the focus of the solution should always be the user. In this case the test is the user.

If we consider the test to be the user then we could also consider test driven development to be user driven development.

The Simplest Answer

The test is a bare bones script which runs expecting certain answers and, if it does not get those answers it fails. Sounds simple enough right?

It’s not. The test itself must be very carefully planned. It must anticipate all possible outputs and test for those outputs. In a very real way the test is a blueprint for the software application and therefore requires a complexity which reflects that responsibility.

However, once the test has been written this allows the development of the application itself to move much faster toward a Minimal Viable Product (MVP).

Imagine you are designing a system. You know what you want the system to do, and you know what goals the system is meant to achieve. However, if you just launch straight into creating that system you will often get caught up in fancifying the system to the point where you are creating problems that don’t actually require solving. It’s like when you see a movie that has all the best special effects but the plot is rubbish.

Test Driven Development allows you to create a system that, to be viable only has to meet a set number of criteria. If you meet those criteria then you have succeeded in your mission. Only then, when the system does what it needs to pass the test, do you add all the bells and whistles.

Every time you add a new element you run the test again until the application/site looks like what you envisaged AND it passes every test time and time again. This means that you will inevitably end up with a system that first and foremost holds the user experience in it’s heart, rather than showing off design or technological knowhow.

To reuse the movie analogy; you ensure that the plot has a beginning, a middle and an end. You make sure that the audience has their emotional payoff, that the characters are fleshed out and that the information provided to the audience doesn’t confuse or distract them. Then, and only then do you add in the lasers and explosions.

Test Driven Development is the Chekhov’s Gun of development methodology and, while it takes a bit of planning the results are an uncomplicated, concentrated development cycle and an MVP to be proud of.

Get in touch