Test-Driven Development (TDD) is a fixture in the software development industry and the gold standard for how engineers ensure they’ve done what they intended to do.
TDD 1 took your team on its first step, by helping them adopt Test-First Programming. However, Test-First Programming is not enough on its own. Over time, tests start to ossify. They become brittle and connected to too much of the system. One developer complained “we have to change 27 tests every time we make a simple change to the system”.
This is not technically a problem with the tests. This is the tests telling your team they have a problem.
The design of a codebase influences the testability of that codebase. Problems in the public API of some bit of code (the “surface area” of that code) will be reflected in, and enlarged by, the test suite for that code. When you run into an issue like “I changed 1 thing and 27 tests broke”, that’s actually an instance of your test suite telling you something about your design.
In this course we focus on paying attention to those signals and addressing the design problems they tell us about. When we fix the problems the tests told us about, we can then adjust the design of the tests themselves to properly isolate concerns and resolve these kinds of “ripple effect” problems.
Recommended Program
The best way to up your team’s TDD game is with a combination of live, expert-led training and coaching. We recommend our TDD 2 program, which includes a 1-day course with 2 days of follow-up coaching so the expert can help your team apply this methodology to their real work.
Course
This 1-day course covers how to use TDD to drive the design of your code, how to update the design of your tests, and how to use tests as concrete analysis artifacts. It has the exercises required to make sure the team has practiced these ideas enough to make them real in their minds.
Topics covered include:- What’s the big problem? (It’s design)
- What your tests can tell you
- Driving design from tests
- Design of tests matters, too
- What do you really want to say with a unit test? (specify external design)
- Red/green/repeat refactor (test-driven design & development)
- Conclusion
The course is interspersed with plenty of examples and exercises to help cement the ideas and practices in the learner’s mind.
Coaching
Afterward, a recommended 2-day coaching package helps learners implement what they learned in their real code using a real PBIs to deliver real code the new way. This is typically done in the same Sprint as the course.
This time can be used in one of two ways:- Start with a problematic set of tests and use it to solve design problems in production code
- Start with a new work item and follow the processes in TDD 1 and TDD 2 to implement it
In the best case, the coach and team will be able to get through one of each of those scenarios but either one will suffice.
The coach will start out pair programming with a lead engineer while the rest of the group watches. Gradually, he will transfer control over to the lead and then step back and let the entire group take over while he provides guidance.
The goal is to help cement these techniques and the underlying mindset for the members of the team so that they can commit to this change going forward.
Benefits
Whereas TDD 1 gives a team what they need to start implementing TDD (namely Test-First Programming), TDD 2 gives them what they need to keep doing it indefinitely.
At the same time, it also gives your team the mental framework necessary to get more value out of their tests.
The result will be code that is more maintainable for two reasons: It is covered in high-value, resilient, meaningful tests and it has a flexible, problem-appropriate design that was driven by those same tests.
Defect rates should continue to drop, and the pace of development is likely to climb over time as the design of the codebase improves and the code coverage increases.
Costs
There are a number of components to take into account when considering the cost of this program:- Impact on capacity
- Time to proficiency
- Risks
- Time to results
Impact on Capacity
This will significantly impact capacity during training and immediately after. The team will not be able to deliver anything during the 1-day course and is likely to deliver at 50% capacity during the two days of coaching thereafter. Therefore, when planning costs, you should consider a 2-day loss of productivity directly related to the training & coaching activities.
Time to Proficiency
You can expect your team(s) to stay in the “practicing” phase of adoption for six to eight weeks.
Risks
Time spent becoming proficient might generate a little additional capacity loss. However, since the team is already familiar with TDD concepts, there is little additional risk to plan for.
Time to Results
One of the major impacts of this program is the continuous improvement of design. It will take the team a significant amount of time in order for enough changes to be built up to the point where the full value of this transformation is visible. In the short run, developer testimony will be the major method to measure success. For instance, are they still concerned about changes in production code creating a “ripple effect” throughout a suite of tests?
