Applying TDD projects is the biggest challenge for many teams because legacy projects are untestable. So I could describe the roadmap for how to introduce testability in a safe way, to enable TDD. I added this to the list of possible guides for the future.
I'd love to have a step-by-step guide to introduce TDD into a team. I've not seen a team where TDD is the standard way of implementing features, and I struggle to show the immediate benefits such that everyone adopts it. The mindset change seems to be quite significant and teams quickly revert to old ways. Something like n X weeks program, from test-last to test-first to TDD, each week adding more TDD knowledge without overwhelming team members?
Yes, that's actually the biggest challenge, since most teams aren't practicing TDD and the architecture is often untestable. Teams might do katas on demos but it doesn't translate to day-to-day adoption of TDD.
I like the idea you propose of a "n X weeks program, from test-last to test-first to TDD, each week adding more TDD knowledge without overwhelming team members". That's like a nutrition/fitness plan, whereby someone who's overweight, we can't just get them to start running the marathon on the first day. Instead, week by week, we slowly change their diet (like reducing calories bit by bit) and slowly changing their exercise (e.g. firtly walk 100m, then 200m, then later light jogging, then sometimes fast running, then some weights, etc..) and each week they are healthier and healther and at some point they have a slim body and are highly active.
Ultimately no one wants big changes - developers would be overwhelmed, and management would never approve.
So applying that to TDD, the week-by-week transition may consist in parallel of both the "soft"/people part (introduce one little mindset-shift this week) and one "hard"/technical part (introduce one little technique, one different practice this week). In such a way, they won't be stressed out, it won't feel like a big thing, and it goes under the radar of management.
I updated the list of guide topics based on this idea (I added the TDD Transformation Guide)
That's a good topic, because refactoring is a crucial step in TDD. Quite often, there is also confusion about when to refactor - at every cycle or not; and also what kind of refactoring we could/should do. Thanks for your suggestion; I updated the list of TDD Guides.
Could you make a guide about how to apply TDD in a legacy project?
Applying TDD projects is the biggest challenge for many teams because legacy projects are untestable. So I could describe the roadmap for how to introduce testability in a safe way, to enable TDD. I added this to the list of possible guides for the future.
I'd love to have a step-by-step guide to introduce TDD into a team. I've not seen a team where TDD is the standard way of implementing features, and I struggle to show the immediate benefits such that everyone adopts it. The mindset change seems to be quite significant and teams quickly revert to old ways. Something like n X weeks program, from test-last to test-first to TDD, each week adding more TDD knowledge without overwhelming team members?
Yes, that's actually the biggest challenge, since most teams aren't practicing TDD and the architecture is often untestable. Teams might do katas on demos but it doesn't translate to day-to-day adoption of TDD.
I like the idea you propose of a "n X weeks program, from test-last to test-first to TDD, each week adding more TDD knowledge without overwhelming team members". That's like a nutrition/fitness plan, whereby someone who's overweight, we can't just get them to start running the marathon on the first day. Instead, week by week, we slowly change their diet (like reducing calories bit by bit) and slowly changing their exercise (e.g. firtly walk 100m, then 200m, then later light jogging, then sometimes fast running, then some weights, etc..) and each week they are healthier and healther and at some point they have a slim body and are highly active.
Ultimately no one wants big changes - developers would be overwhelmed, and management would never approve.
So applying that to TDD, the week-by-week transition may consist in parallel of both the "soft"/people part (introduce one little mindset-shift this week) and one "hard"/technical part (introduce one little technique, one different practice this week). In such a way, they won't be stressed out, it won't feel like a big thing, and it goes under the radar of management.
I updated the list of guide topics based on this idea (I added the TDD Transformation Guide)
It would be nice to see a TDD Refactoring guide, and how to do our best in the refactoring phase of the TDD cycle.
That's a good topic, because refactoring is a crucial step in TDD. Quite often, there is also confusion about when to refactor - at every cycle or not; and also what kind of refactoring we could/should do. Thanks for your suggestion; I updated the list of TDD Guides.