"The other reason why we didn’t just jump to TDD is to enable the team to feel the pain of retroactively redesigning architecture & code to be testable, and to see the low mutation code coverage scores (despite high code coverage scores) - to see that the tests they’d write with Test Last wouldn’t protect them against regression bugs."
This really resonates. As Bob Martin points out (https://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html), mutation testing makes Test Last possible, but it also makes it really painful. Once a team experiences this pain, TDD (with its guarantee of full behavioral coverage) is a breath of fresh of fresh air.
- Rapid Coding Inner Loop (R-G-R) depends on Test as Spec, Fast Consistent Automated Tests and Reflexive Design (and, ideally, Pair/Mob for Discipline)
- Fast, Consistent Automated Tests depends on Automated Developer Testing and Code in Small, Testable Units (and, ideally, on Test as Spec and Pair/Mob for Productivity)
- Test as Spec depends on Automated Developer Testing (and, ideally on Work Together to Learn)
- Reflective Design depends on Don't Repeat Yourself, Naming as a Process/Safely Modify Legacy Code and Iterative Team Improvement (and, ideally on Pair/Mob for Disciple, or at least on Work Together to Learn)
- Don't Repeat Yourself and Naming as a Process/Safely Modify Legacy Code depend on Local, Transform-Based Refactoring (and, ideally, on Work Together to Learn)
Yes, those are exactly the reasons why I delay TDD, rather than just jumping into it.
(This is where I may differ from other Technical Coaches - there are some who would immediately jump into TDD, but I don't)
Indeed, feeling the pain of Test last is the best way to have motivation, and then to appreciate TDD. That's why in coaching, I want the team to go through pain of retroactively introducing testability and having to retroactively fil up the test suite at various levels (ending with unit testing fill-up based on mutation score).... and then try TDD, and then I ask them to compare how they feel with the both ways.
This was far better than just showing a PPT with TDD benefits.
Instead, I get the team to come to these realizations themselves.
How about you, which transformation pathway do you tend to use with teams working on legacy projects and introducing TDD?
Thanks a lot for sharing this, Valentina. Since our industry is developing rapidly, there's always an opportunity to make things better. But in a large enterprise-grade company with many issues, it is challenging, extremely tough, and takes so much effort that far not everyone will be mentally able to push for it.
You can change the company, or change the company ;)
Correct. It's too hard to find a company that is already practicing all of these technical practices, so it's best in our current company (esp. if we have support from management and colleagues, supportive environment) to start the transformation process.
It's very motivating to see how TDD transformation is possible with determination!
Indeed, it's not a 1-week journey, nor 1-month journey, but took years. A key learning from Nik's story is he persevered.
Nik had an amazing journey. Always fun to learn from him.
Yes, I really appreciate Nik's posts on LinkedIn, highly recommend to readers to follow him too.
I'm interested to hear more about what's your biggest learning from Nik?
"The other reason why we didn’t just jump to TDD is to enable the team to feel the pain of retroactively redesigning architecture & code to be testable, and to see the low mutation code coverage scores (despite high code coverage scores) - to see that the tests they’d write with Test Last wouldn’t protect them against regression bugs."
This really resonates. As Bob Martin points out (https://blog.cleancoder.com/uncle-bob/2016/06/10/MutationTesting.html), mutation testing makes Test Last possible, but it also makes it really painful. Once a team experiences this pain, TDD (with its guarantee of full behavioral coverage) is a breath of fresh of fresh air.
Two more reasons to delay teaching of TDD:
a) Develop the mindset that a "A Test is a Spec."
b) Develop refactoring skills
Note Arlo Belshee's Agile Engineering Fluency Stages of Practice map (https://arlobelshee.github.io/AgileEngineeringFluency/Stages_of_practice_map.html):
- Rapid Coding Inner Loop (R-G-R) depends on Test as Spec, Fast Consistent Automated Tests and Reflexive Design (and, ideally, Pair/Mob for Discipline)
- Fast, Consistent Automated Tests depends on Automated Developer Testing and Code in Small, Testable Units (and, ideally, on Test as Spec and Pair/Mob for Productivity)
- Test as Spec depends on Automated Developer Testing (and, ideally on Work Together to Learn)
- Reflective Design depends on Don't Repeat Yourself, Naming as a Process/Safely Modify Legacy Code and Iterative Team Improvement (and, ideally on Pair/Mob for Disciple, or at least on Work Together to Learn)
- Don't Repeat Yourself and Naming as a Process/Safely Modify Legacy Code depend on Local, Transform-Based Refactoring (and, ideally, on Work Together to Learn)
To summarize, the building blocks are:
a) Collaboration, Continuous Improvement
b) Testing, Refactoring
c) Reflexive Design
d) TDD
Yes, those are exactly the reasons why I delay TDD, rather than just jumping into it.
(This is where I may differ from other Technical Coaches - there are some who would immediately jump into TDD, but I don't)
Indeed, feeling the pain of Test last is the best way to have motivation, and then to appreciate TDD. That's why in coaching, I want the team to go through pain of retroactively introducing testability and having to retroactively fil up the test suite at various levels (ending with unit testing fill-up based on mutation score).... and then try TDD, and then I ask them to compare how they feel with the both ways.
This was far better than just showing a PPT with TDD benefits.
Instead, I get the team to come to these realizations themselves.
How about you, which transformation pathway do you tend to use with teams working on legacy projects and introducing TDD?
Thanks a lot for sharing this, Valentina. Since our industry is developing rapidly, there's always an opportunity to make things better. But in a large enterprise-grade company with many issues, it is challenging, extremely tough, and takes so much effort that far not everyone will be mentally able to push for it.
You can change the company, or change the company ;)
Which game do you go for?
Correct. It's too hard to find a company that is already practicing all of these technical practices, so it's best in our current company (esp. if we have support from management and colleagues, supportive environment) to start the transformation process.