Test Driven Development (TDD)
Test Driven Development is a software development technique which suggest writing tests first than writing the code. It was introduced by Kent Beck in the late 1990’s and got popular in 2000.
- Write a test that fails
- Write the minimal code which is required to pass the test
- Refactor the code
- Improve overall maintainability: With TDD, it is very easy to maintain the code and identify the bug
- Make code extensible: It is easy to add or modify feature and ensuring that the existing code is intact.
- Less # of bugs: There will be very less # of bugs as team practice TDD and writing test cases for each feature & functionalities.
- Early Feedback: As the developer will be writing the test cases before the code so they can share the feedback on feature if something is missing in acceptance criteria.
- No dependency on the developer who developed the code: Anybody from the team can start working on new feature or modify existing feature.
- Automation: With TDD, test will be automated which ultimately saves lot of time as compare to manual testing.
- Less time in fixing the bug.
- Improve code quality: Code quality will improve as tests case are in place for each and every functionality.
- Early bug notification.
How to verify TDD is being followed by team?
- By checking Code Coverage: When team is following TDD then the code coverage will be more than 80%. Although code coverage neither guarantee the appropriate use of TDD and nor it tells about the quality of test cases. But, below 80% coverage shows that there is lot of improvement is requirement in a team mastery of TDD.
- By verifying version control logs: Test code should be checked in each time the product code checked in.
When TDD Fails
- Developers are not having enough knowledge on unit test framework.
- TDD approach is not clear and developers are concerns in writing the code and not following the TDD cycle.
- Complex scenarios requires great amount of time in creating test cases and team is not willing to put the required effort or management is not willing to give that much time to developers.
- Requirements changes frequently which makes creation and maintenance of tests difficult.
- Architecture of the application doesn’t support especially when there is a tight coupling between the components.
- Partially adopted by the team meaning few developers are following TDD and not all.