Benefits and Limitations of Test Driven Development (TDD)

Test Driven Development - TDD

Test Driven Development (TDD) is also called test driven design. TDD is a method of software development in which source code is tested over and over again (unit testing).

Just like any other concept, TDD also has some benefits as well as some limitations that are as follows:

Benefits of Test-Driven Development

As the application modules are continuously being tested after development so a state of confidence is also being developed that product is stable. Developers are free from the fear of already built functionality breakdown.

Maintainability, Flexibility and Extensibility:

TDD ensures that each unit can be tested and can be changed. When even a minor change is made, all test cases are run to check how much it has impacted other units. This removes all the hurdles from updating application and committing changes within current sprint.

Unparalleled Test Coverage & Streamlined Codebase:

As TDD is test first and code later approach so there may never be a chance of skipping a test before developing a code. Refactoring ensures that the code is economical and streamlining codebase. It helps in maintenance and resolving the scope problems.

Executable Documentation:

TDD use cases as they are written as test cases helps developers understand how their code should work.

Limitations of Test-Driven Development

  • It takes a lot of time and effort which creates a sense of slow development.
  • TDD focuses on simplest design for current sprint and doesn’t tackle for future major refactoring.
  • Sometimes it’s not easy to write the test cases which are specifically related to the feature under development.
  • In TDD, design gets changed rapidly. A lot of time could be spent in writing test cases for the features which will not be the part of the product.
  • It’s hard to test the interface because of continuous changes.

Things to Avoid while Writing Test Cases

  • Don’t write test cases that depend upon system state generated from the execution of last test case.
  • Test cases should not be dependent on each other. For example test cases belonging to a test suite that are dependent. Their order of execution is presumed not analyzed.
  • Interdependent test cases could cause a failure. For example a test case failed at an early stage could cause the remaining test cases to fail.
  • Testing the execution behavior timing or performance.
  • Testing the implementation details.
  • Writing test cases which run more slowly than the actual time of execution.

If you know about some other TDD benefits and limitations, then do sound off in the comments section below!