Anyone who has worked on an I.T. project will know this familiar scenario: a project with a tight timeline has a bug that needs fixing before deployment. Once the code has been written, manual testing is performed before the code review is done, and the code is merged to the source control. You then run the risk that more bugs and issues may have been introduced from the code merge; meaning that you’ll either need to write more tasks to resolve this issue or the new code changes will need to be reverted in source control.

A lot of things could lead to problematic code. The following are a few main reasons for this:

• Lack of test cases written for the application
• The tests were written after writing the functional code
• Failing to regression test

So how might be avoid this scenario? I suggest using Test-Driven Development (TDD).

What is TDD

TDD is an approach to development that emphasizes testing code before the code is written.

In the first step, the developer writes the test. Then, the test is run to see if it fails. This state is called “Red” because in most of the frameworks when a test is failed it is highlighted in the color red. The reason for running the test before writing the code is to make sure it fails the way the developer expects it to. If, for any reason, if a test passes at this moment it means that there is something wrong with the test itself.

After that, the developer writes the minimal code to see if the test passes. This state is called “Green”. Finally, the code and the tests are refactored to make them clean, simple, and readable. This state is called “refactor” which makes the code ready for the next iteration of writing the test, then writing the functional code, and refactoring again. This is called the “Red-Green-Refactor” approach of TDD.

My experience using TDD

When I first started using TDD, it was not easy as it seemed. It took some time and practice to understand how to write the tests before writing the code. After some time practicing TDD, I saw the magic; I started to write the code faster and was able to spend more time in the planning phase rather than spending time fixing bugs later on.

Initially, while code reviewing, I realized the code quality had gone down and more effort was required in the code review phase. Over time, as the team became better aquainted with TDD, the code quality got even better than what it was before implementing TDD. This is because the team started to write the code in smaller testable chunks, which made unit testing as well as integration testing easier and debugging faster.

As TDD requires developers to write extra code, it made some of the developers in our team hesitant at the start. To overcome their hesitance, we chose smaller tasks to acquire the skill and implement it. Developers learned the process at their own pace, we gave them the time and assistance they required to master this framework, and ultimately as the team matured, development, debugging, and refactoring time reduced considerably.

Value added by TDD for me

Test-Driven Development allowed me to write higher quality code. By “higher quality” code, I mean that the code is reliable, maintainable, loosely-coupled, has high cohesion, is easily testable, modular, reusable, and has good separation of concerns.

Now I am able to spend more time focusing on the functionality details before implementing it. With TDD, I can plan on how to go about writing functional code in the early stages of software development. The bug count has also been reduced considerably as I am able to identify any missing functionality in the early stages of development.

#coding #test-driven-development #tdd #testing #programming