Test-Driven Development (TDD)

What is test-driven development?

In simple, write the tests first, write functions and features later! Take a look at the flow chart below, this gives a brief overview of the process.

I will shortly describe this flow chart, however, let's start by first talking about the advantages of TDD and why you may want to utilize it in a project. As I previously mentioned this process starts with tests, then code. This, in short, helps you produce reliable code and break complex problems into easier bite-size chunks. With TDD we write a test, run the test, watch it fail, then write the minimal amount of code to pass the test. This helps us keep our focus in a more constructive manner, solving the functionality of a program piece by piece. Ever stared at a method for hours on end wondering how you’ll solve it, how to make it reliable for future implementation? TDD is the way to go!

There are a number of testing tools out there to test code, all with there own little unique quirks. An example of just a few would be RSpec for Ruby, Jtest for Java, Blue Ridge for Javascript and Google Test for C++. Which one is suitable for your application is all down to compatibility and your personal preferences.

Now let's break down the flow chart, what is the user story? Let's give an example “As a user of program X I want to be able to add two numbers together”. Well, that's pretty easy, write the test first! A hurdle of TDD is the question “How do I write a test for something that doesn't exist?” which is a fair question. Write a test to see if the method exists within your program (it will no doubt fail the first time you run it, but that's what we want!). Write the minimal code to pass that test, just simply define the method so it’s in your code and watch that test pass. You’ll find each time those tests pass you’ll get a little hit of dopamine, I personally actually find TDD a great way to stay motivated.

Continue with this process throughout the program, ask yourself some of the following questions; “Does a method take arguments?” “What should the return value be?” Each time you add a little more you’ll build towards the finished product, refactoring the code as you go. Another great byproduct of TDD is you’ll constantly be running unit tests, which may raise the question of what separates this apart from unit testing, it does the same thing right? Well no, TDD is all about the process in which you solve a problem, unit testing is for sure an amazing thing however it lends itself more to completed sections of code.