Test driven development

Jorge Andrés Pietra Santa Ochoa
3 min readNov 19, 2018

This is a software development process that helps us avoid duplicate code, making it clearer and easier to read and comprehend, facilitating early bug detection. This is a process that is repeated several times during very short development cycles. With this, you need to transform your requirements into test cases, and with each cycle, your software is improved and is now ready to take on a new set of tests. With this, you’re always making sure that you software meets all the requirements.

Requirements

For each new piece of functionality of an application, a new test is created to make sure that it works as intended. Each test represents a new requirement that our program needs to fulfill. In case a test fails, the developers are forbidden from writing new code before the existing one is corrected. The idea of this is to develop and run the tests before the actual development of our application.

Adding a new test

Before we implement any new feature, we first write a test case scenario. This test will define how a new function will work, or how an improvement should reflect on the performance of an existing method. For this, we assume that the programmers fully understand the feature they’re about to add, and how it helps us check the requirements of our application. In some cases (such as improvements to existing code) you shall recycle existing tests. The whole point of creating tests before the code is written is so that the developers have a clear image of what the program should be able to do and focus solely on that.

Fail a test

Running previous and new tests

We now test our code to make sure if the new test is passed. If the code that’s already available can pass the new test, it means that the new test isn’t really new, and is therefore useless. A new test is always required to break the program, since the purpose of creating a new one is to add functionality that’s not already available.

Writing just enough code

Our next step is to write new code that is able to pass the new test. It doesn’t matter if this new piece of code is well-written. The most important aspect of this test is to make sure that we know how to solve the problem at hand. However, as easy as a new piece of functionality may seem, we must control ourselves and focus on solving the current test, and avoid adding any new functionality before it is required.

Re-run

Re-run tests

This is just to make sure that our new piece of code actually passes the test. Here we make sure that it’s able to add new functionality without breaking previous code.

Refactor code

The last step in our short cycle is to clean the mess we just made. Remember that it didn’t have to be well-written? Well, now it does. We move it around and restructure our code so that each piece of the new functionality is where it actually needs to be. We delete duplicate code and follow the OO principles to make sure that your new code is readable, understandable, and easily-maintainable.

Now all that’s left is to repeat this cycle as many times as it’s needed. By repeating this process, you make sure that your code is always well-written and well-implemented, so that you can make changes whenever needed without having to change the whole logic of your program.

--

--

Jorge Andrés Pietra Santa Ochoa

Decently-fed student majoring in Computer Science. You probably don’t know me, but you will.