TDD (Test Driven Development) is good or bad for you?
Answers to this depend on various factors. Maybe you need my opinion instantly, but it's really hard to give you a true answer.
This article is written to help you understand a case study which has collected experience of 4 different teams that have adopted TDD. Those teams are from Microsoft and IBM.
All four teams have different contexts in their working.
You might have similar context like them, or can have different as well.
But if you believe TDD is better for specific tech-stacks, or specific type of project. Then you my friend you definitely should see what these teams were working on.
The project and the teams
IBM
Their legacy product of device drivers has gone through several releases since 1998, and in 2002 they chose a new platform and moved to a completely new architecture and adopted TDD as well.
Their legacy system and new system had similar output, but with different approaches and tech stacks. Comparing both releases is not as balanced as you might be looking for, but still it's valuable to see what difference they had.
Microsoft
The TDD and non-TDD projects under above mentioned areas are developed by teams led by project managers with similar levels of responsibilities and reporting to the same high-level manager.
And here we will get a great balance to compare project values and find what TDD experience has been for teams.
Summary of Team Factors
Varying Contexts in case of these 4 teams
Still, results of case study indicate that pre-release defect density decreased between 40–90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.
I am still neither with TDD nor against it, but further in the article you will see some points with which you might be able to relate and understand these teams' experience.
TDD Implementation
The IBM team ….
who was responsible for device drivers parts made a pretty clear process for them in my views.
They got detailed specifications in-hand, they most of the time work on test case first to reduce ambiguity and to validate requirements.
They had set up a build system, which daily extracts the code, runs the test cases, and fires email to all people involved with a report of success and failure.
This daily integration setup came handy for them as part of validation and pushed them to keep things green and get a better report than last day. They target to keep 80% minimum all the time, it can't go below.
And there were legacy teams as well doing similar work with TDD but not that much dedication with TDD as the above team was. It missed quite a few steps.
And then comes, Microsoft teams
They had this Hybrid-TDD approach, where they followed TDD, but didn't adopt agile methodologies completely and also had design meetings and review sessions.
Their testing process had a variety of tools in addition to TDD, such as static analysis, dependency analysis as well as fault injection tools.
As there were 3 different teams here, some were aligned to running TDD in the command line, some had a step of triggering email for analysis purpose. But the teams were lacking any particular coverage measures goal like the IBM one had.
What's the outcome of TDD in quality and productivity for teams?
Increase in development time ranging from 15% to 35% if offset by the reduced maintenance costs due to improvement in quality, an observation that was backed up by the product teams at Microsoft and IBM.
Conclusions of case-study by researchers from this experience
- TDD can be applicable in various domains. If you never heard of TDD in your type of project, how about you experience it?
- It's team belief that TDD is able to significantly reduce the defect density without significant productivity reduction. There is a balance which people experience and decide which way is better for them and for their work.
- Additionally future releases will also experience low defect densities due to use of test assets. Assets like unit, functional, integration.
What to remember if you choose to experience TDD?
- Go with facts of other people's experience, and then choose to start or not to start. Don't overwhelm yourself with so many opinions on the internet.
- Start TDD from the beginning of projects, because it seems to have advantage if done incrementally and continuously.
- Convince the team to add a test case every time a problem is found.
- Share unit tests with each other, collaboration is good for betterment of tests.
- Track count of bugs found and fixed, source code count, test code count, code coverage, trend across time to always look back if TDD implementation you chose is working for you or not.
- Check the morale of team members in the beginning and end of the project. If it's not providing value to them, something definitely needs a change.
References
Paper case study on which this article is based upon - Link to case study paper
Top comments (0)