Test-Driven Development (TDD): Why It Is a Good Idea
November 26th, 2015
You might've heard of TDD, but it often appears to be quite a confusing thing. Why should you consider this practice and what are its pros and cons?
What's the main idea?
Wikipedia defines TDD as a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Test-driven development means a change of the development sequence. Tests are written before the features are developed.
- Traditionally, the process goes like this: Design > Code > Test & Integration.
- However, in TDD, it goes like this: Design > Test > Code > Integration > Payoff.
Looks like the latter process takes longer, but in reality, it is quicker, if set up correctly.
What is required for a successful TDD to be implemented?
- Committed and focused management - it should not be just a random decision as in "We've heard at a conference that it's a good practice, let's do it."
- The team that is motivated, confident, and onboard - without the coders who are on the same page with the management regarding the necessity and usefulness of TDD.
- Time to train developers and implement it - it takes effort and the switch does not happen within one day, but life's like that all the time :) So prepare to allow some time for your team members to adjust to the new methods.
- Sustained efforts at cultural change - some cultures might be more open to change than others, so consider those issues too and respect them.
- Open communication - can we stress this point enough? Create an atmosphere where developers and managers can communicate openly about the issues as they arise and chances are that there will be fewer problems and bugs (even if you end up not transferring to TDD, open communication is one of the most useful tools for team building.)
The benefits of implementing TDD
There are quite a few pros to this method. One of the main one being reduced debugging efforts because your code is written with the tests in mind.
The challenges of TDD implementation
While it is one of the best practices on the market, there are a few cons to the method as well.
Things to avoid while implementing TDD
- Using previously executed test cases over and over. Creating a "perfect" test is nearly impossible (not to mention, quite inefficient because of all the efforts it would require) so create new tests for specific cases. It's not like you're developing the same feature over and over and over again, right?
- Dependencies between test cases. Again, if you're working on a new feature, do not reuse old tests (even if your test is new, but uses information from another one.) Also, even if both tests are brand new, dependencies can cause havoc when the execution order would change.
- Building "all-knowing oracles." This test would most likely check more information than necessary and its creation would be more expensive. Besides, think of the fact that one single tiny error in your "oracle" would kill the test.
Do you think TDD is something that you'd like to implement in your future projects? Are you using that method already? Share in the comments!
Let's develop a great product together!
