Everyone that has worked on an I.T. project will be familiar with the following 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. After manual testing, the code review is done and the code is merged to the source control. Later on, more bugs/issues could be found somewhere else in the application that got introduced with the code merge. Either further tasks will be written to resolve the issue or the code changes will be reverted in source control.

A lot of reasons could lead to problematic code. However, following are a few main issues;

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

To avoid above mentioned scenario, we choose Test Driven Development. This is where TDD (Test Driven Development) shines, but first let’s talk about what is TDD.

What is TDD

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

In the first step, 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 as Red. The reason for running the test before writing the code is to make sure it fails the way developer expects it to. For any reason if a test passes at this moment means, there is something wrong with the test itself.

After that, the developer write the minimal code to see if the test pass. 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 next iteration of writing the test-then writing the functional code-and again refactoring. This is called Red-Green-Refactor approach of TDD.

How was it at the start

At the start it was not easy as it seemed. Writing tests at the start was taking more time. 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 as well as, I was able to spend more time in the planning phase rather than spending time on fixing bugs later on.

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

As TDD requires developers to write extra code, it made some of developers in our team hesitant at start. They felt manual testing is easier than Test Driven Development. To overcome their hesitance, we chose smaller tasks to acquire the skill and implement it. Developers learnt the process at their own pace. We gave them time and assistance they required to master this framework. Ultimately as the team matured, development, debugging and refactoring time reduced considerably.

#testing #programming #developer