Test-Driven Development (TDD) Principle

Test-Driven Development is a Software development practice, and which helps to write more clean codes. In TDD, we write the test case first for a specific feature. And then we write code of that feature and validate whether the required output is coming or not from that feature. If everything is working fine than refactor the code base, otherwise make effort to get the required output from that feature. That is basically the TDD principle(TDD life cycle)

We can make code coverage as 100% by applying TDD principle to our project. The reason we have 100% code coverage is that TDD principle is a Test first Approach. Since we always refactoring the code may help us to avoid duplication, apply design patterns, apply more polymorphic behaviour, and make our code more object-oriented

code coverage is a measure used to describe the degree to which source of the program is executed a particular test suite runs.

code coverage = (tested source code / whole source code) * 100%

I recommend basically more than 85% code coverage is better.

TDD Levels

There are 2 identified levels for TDD

1. Acceptance TDD (client level)

Here we do the acceptance testing focusing on requirement specifications or behaviour of the system.

2. Developer TDD (coding level)

Here we do the unit testing focusing on small functionalities.

TDD Phases

1. RED: write the failing unit test for the feature.
2. GREEN: Write just enough code needed to pass that failing test. Do not bother about code quality at this stage
3. REFACTOR: Refactor your code if possible

TDD Life cycle

First, we write the test case for some feature (suppose that is some kind of unit test case). Then we need to code the feature for that test case. In this phase, you are free to code anyway. Don’t care about OOP concepts here just code it what you think. And then validate that feature with a test case. If it fails then change the code base and make sure to have current output. Once you have passed the validation test, then tend to refactor the code by applying design patterns and all the stuff you know to make your codebase very clean. and finally, repeat the cycle again and again.

Question: How much time we spend to write the code and refactor the code?

Honestly, there is no answer to that. But I think the same amount of time we need to allocate for writing bad code and writing good code(refactoring)

TDD Pros

• Driven by clear Goals
• Safer code
• isolate incorrect code
• Easily introduce the application
• Document the application
• More object-oriented code
• Higher rate code coverage

TDD Cons

• Initially, it slows down the development
• Test cases are difficult to write beyond the unit test level
• Time-consuming
• The whole team must need to correctly maintain the test, or otherwise the system can quickly degrade