Test Driven Development: Making sure your code is doesn’t sh*t itself to much.

In my early years of programming, I would write some code without much thoughts. I did not fully understand the concept of testing a code, I thought “Oh let me write some code and run it then see if it works.” It would end up very time consuming as I changed a few lines, then executed the code and did the necessary actions on the application to test that part of code and then be stumped on why my code is not working. If it did work, then I would move on to the next functionality and repeat the process. Sometimes, the part of the application I was working on would run, but then some other part would f*ck up. After all of that, I would write my tests just to satisfy some assignment qualification. From my anecdote, it can be seen that I was very inefficient in writing my code.

Then I found the concept of Test Driven Development.

What is Test Driven Development?

Basically, Test Driven Development (TDD) is an approach to the way we code in which tests are written to validate and decide what the code will do. In other words, write tests first then implement code that passes the tests. If the tests still fail, then write new code. In doing so the way the code is written is much more structured and organized.

TDD pushes programmers to think what their code will do and then design unit tests to test functions of their code. The developer will only write new code when the unit tests fails.

Here is a simple illustration of how TDD works:

How to TDD?

The how is pretty simple, just follow these few steps:

  1. Create or add some tests

2. Run the tests and see if they fail

3. Write code

4. Run tests and refactor code accordingly

5. Repeat from step one until the program is according to desire/requirements

Some important things to note is that when writing tests, make sure you properly determine what function you want to test before writing the test and code. If you work on a project with clear requirements then ensure the tests are written accordingly.

An Example of Implementing TDD

Currently I am working on a group project to develop a mobile application and we use TDD on approaching it. So how do we do it?

Well the basic cycle remains the same but in our group project we use git. So when one step of the process is done, we commit the code with a certain message. There are also clear requirements on the application we are developing, so the tests written are adjusted accordingly. The modified process is as follows:

  1. Pick a functionality/requirement that needs to be met.

2. Write tests for that function. Commit the newly written tests with commit message along the line of “[RED] Made X Function Test “

3. Write code.

4. Run tests and if passed, commit with message: [GREEN] Implemented X Function

5. Refactor (If needed), with commit message: [REFACTOR] Refactored X Function

Refactoring code is usually optional. It usually happens when we want to make an algorithm more efficient or code more cleaner. If you are satisfied with the code, this step can be skipped.

6. Repeat from step 1 until all requirements of the program are met.

That is a small snippet of TDD on git. I will explain git flow on another article. Everyone on the group is required to follow this process. “But why?” you ask.

Why you should use TDD in almost any project?

There are many advantages to using TDD during software development.

  1. Minimizes bugs and errors in the program/application
    Usually TDD results in more tests being written because we are much more thorough about the code we write. More tests means more code coverage and less likely to come across a bug that isn’t covered in the code.
  2. More focused coding
    From the process I explained earlier, when writing a test we pick a functionality beforehand. So during an iteration, we are more focused on finishing that functionality and less like to wander off to other functionalities that also need to be met.
  3. Modularity
    Because of the “pick one functionality” mindset from this cycle, the code we write tends to become less dependent on other code (or modular). This helps prevent programmers from breaking the program when writing the program.
  4. Safe refactoring
    When refactoring, we have a safety net of tests to ensure when we make a mistake while refactoring, we can catch the mistake after running the tests. This also prevents programmers from accidently breaking the program when refactoring something. Preventing any mistakes like the ones I made in my initial story.
  5. Tidier Code
    Because TDD causes the code to become more modular, the code we write tends to be more tidier as well.

TDD has personally helped me and my group very much. Because everyone is required to do so, I personally can be more confident on continue working on someone else’s code with a safety net of tests. There is also less concerns for bugs overall because we try and aim for the highest code coverage possible. Less bugs bring less stress to everyone and more happier programmers. There is also an assurance of quality that TDD brings to the software. With TDD, it is also easier to split tasks amongst members. Like in my project, I could be focusing on the login function, whilst my friend is working on a map function.

So, in conclusion TDD is a very useful approach that you should start using on any software project. May your code be more clean and your coding be more efficient!

References: