Revolving around Tests

Photo by Annie Spratt on Unsplash

In a world full of technological advancements, where minds wander and thoughts are filled with innovations, there are some things we cannot forget:

Process.

Thomas Alva Edison does not just invent the lightbulb in one go, we all know that. The process of being able to find the right material inside the lightbulb is an arduous one, albeit fruitful. This does not just apply to lightbulbs, but to every aspect of life.

Photo by Patrick Tomasso on Unsplash

Just like what Edison did, developers also need to find what works and what does not within the code. To be able to do this, we use a method called TDD.

What is TDD?

TDD is an abbreviation for Test-Driven Development. Unlike Edison that tests his lightbulbs after the materials were changed, in TDD we test it first and then write the code.

Why?

We write tests to make sure that the program does what it needs to do, like a guideline checklist, in some way. This is to make sure that the code works the way it should.

Why test first?

The reason behind this is simple. It is a type of black-box testing where the tester is unaware of the code and implementation of the application. Just like a user, who has no idea of how the internal structure and design of the code is like.

TDD Implementation

1. Create a test and make it fail on purpose [RED]
   write just enough code so it could compile and check only what needs to be checked or the function you were checking
2. Make the test pass [GREEN]
   To do this you might change and add or even delete the lines of code inside your function.
   Please remember to not do things more than necessary!
   Run the test and check if the test has passed or if there are any errors.
3. Refactoring [REFACTOR or BLUE]
   This is where we implement the clean code, refactoring means that we get rid of the unused lines of codes, making sure that there is no replication or repetition in the code.
   Clean coding will be further explained as you read along!

And that is all the steps to implement TDD!

The Implementation in my team

What my team are currently implementing is the TDD I had just explained. Where first, we write the tests and commit it to GIT with a commit message [RED] because the pipeline will (and should) fail since the only thing that is written are the tests.

Next, we add the codes, i.e models and other internal structures required to create the application. After making sure that we have everything that we need to make the program work covered, we can try to run the test and check if the tests work now. If it does work, we can commit this to GIT with a commit message [GREEN], explaining that the code has passed the tests.

If there exists a refactoring to be done, we can edit the code and commit it with a [REFACTOR/BLUE] as the head commit message, indicating that it is a refactoring.

Advantages in TDD

1. Developer’s productivity and time
   Since the developers will only write the required lines of code to make sure that the application works the way it should, the less time it will take the developers to make the application. The developer also does not need to add unnecessary lines of code since the only ones needed are the ones that could make the test to be run. It does not mean it will not be taking a long time, just a more efficient one if compared to the non-TDD method. The time difference could be used to do other things.
2. Better code
   Since the code will only cater to the required tests, the code will be less messy. Developers will think what do they need first and then write the code, so it will really only be consisting of what is required.
3. Higher test coverage
   Sometimes, if we do not start with tests first, it might be hard to make the tests and reach the required test coverage. On the other hand, if we make it in a TDD form where we write the tests first, we can make sure that the code that we write can be used for the tests and not the other way around.
4. Knowing Errors
   With creating useful and required tests, we will know whether our code works the way it should or not. This is just like any other checking method developers has (i.e putting prints to check whether the line are executed or not). This makes the code easier to debug.

higher test coverage, thanks to TDD

A topic that is really closely related to this is Clean Code, but we’ll talk about that in another time!

Thank you for tuning in!