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. The first step to adopting TDD is incorporating a practice known as Test-First Programming into your daily routine.
Recommended Program
The best way to kick-start your team’s journey to TDD is with a combination of live, expert-led training and coaching. We recommend our TDD 1 program, which includes a 1-day course, along with 2 days of follow-up coaching so the expert can help your team apply this technique to their real work.
Course
This 1-day course covers the basics of Test-First Programming along with all the requisite skills to make it work, along with the practice required to make it stick.
Topics covered include:
- Intro & Establish problem (developers cannot move with confidence)
- Solution: automated testing
- What it could be like (a demo of test-first programming)
- Tests as specifications
- Anatomy of a test
- The relationship between tests and behaviors
- Red/green/repeat (test-first programming)
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 usually completed in the same Sprint as the training. This is essentially immersion therapy to overcome any emotional resistance developers may have to writing their tests before they start writing their production code.
During these sessions, the coach will lead the team members through several cycles of the following.
- Discuss test-writing with coach
- Write a test
- Review by coach
- Write/update production code
- Review by coach
The goal is to create familiarity and comfort with the Test-First process. Along the way, the engineers should experience some of the benefits of writing tests first, further reinforcing adoption of the process.
Benefits
Over time, your team will begin to accumulate meaningful test coverage at the unit level. These tests will serve as documentation of developer intent and will “stand guard” against breaking changes going forward.
It is difficult to overstate the impact of a successful transformation.
Engineers will feel safer changing code that they know is fully specified and enforced by tests. They will be willing and able to move faster. They might make fewer mistakes because the tests serve as technical documentation (to some extent). However, even when the team does make a mistake, the presence of a suite of tests increases the chances that it will be caught before it “escapes” to a wider audience.
From outside the team, you will see fewer escaped defects, less rework stemming from technical mistakes, happier engineers. Ultimately, these things will manifest as increased productivity – both from the team having more productive time on account of spending less time on remediation of errors and from them feeling safe when moving faster.
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
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 to proficiency may create some additional capacity loss but, most likely, it will express in the form of mistakes. It is very likely that a team (or teams) will fail to write tests when they should, write tests when they shouldn’t, write the wrong tests when they do write tests, and write the correct tests the wrong way. The cleanup of these mistakes should be factored in when planning for the cost of this transition.
Prerequisites
none
Enablers
none
