See the presentation : https://www.youtube.com/watch?v=E2d2BYxOiME
Summary
When you write tests or refactor at the end of a story, or worse in a separate story, who gets the benefits? And when?
Unfortunately it's the next person who touches the code ... sometime in the future ... if we're lucky. Given that the tests remain relevant. And given that the refactoring actually helps with the new functionality, that we don't know yet ... 🤔
That means our efforts in refactoring and tests are primarily for other people, sometime in the future and of uncertain value to them. Is it surprising if we don't do much of it and let the code rot?
An alternative, that maximizes the ROI of the tests and the refactoring, would be the Protect-Prepare-Produce method 🧐.
Protect
Write quick and dirty(!) tests to protect refactoring in the next step. Beware this can hurt some sensitive viewers.
Prepare
Refactor in depth to make the new functionality easier. Also make the code testable and improve the tests written in the previous step.
Produce
Code the new functionality in TDD. Should be a piece of cake given the Prepare phase.
Being the primary beneficiaries of the testing and refactoring we do ourselves means more happiness. With a much better ROI on testing and refactoring, we're likely to have a lot more of it.
Let's make this clear with a few examples. Not the least what I mean by QUICK and DIRTY tests.
ABOUT JOHAN
Johan Martinsson is a freelance dev coach, passionate about code and software design.
A serial kata-creator and co-creator of conferences SnowCamp and AlpesCraft, facilitator of regular meetups since 2009, he often finds (good) excuses for showing code at conferences.
LinkedIn: https://www.linkedin.com/in/jomartinsson/
Twitter: https://twitter.com/johan_alps
GitHub: https://github.com/martinsson
Blog: http://martinsson-johan.blogspot.com