paulbellamy.com

Testing With Intent: Legacy and Refactoring

8 February, 2019

Bringing TDD Into an existing organization

Beginning a testing practice in an existing organization is much harder than starting it on a fresh project. TDD even more-so. When there is already inertia, and outside pressure, changing course takes a long time. But, once that inertia is in the right direction, it will be unstoppable.

Where to begin? There are three different approaches. Depending on your organization, each can make sense. They are:

Whichever approach you choose, you’ll end up creating little “pockets of TDD” within the bigger system. When working on new components, define their boundaries within the bigger system, and TDD the new component.

Testing legacy systems

When testing legacy systems, there are three key steps to go through.

Any time you’re working on a legacy system it is important to pick and choose your battles. Is the system critical? Does the system break? How often? Are we working on/replacing it? The answers to these questions will help you decide if this work is worth doing.

Cultural Shift

Testing demands a cultural shift. It requires acknowledging that there will always be outside pressure to ship faster. To “move fast and break things”. To skip and bodge the solution “for now”. Instead, we need to purposefully focus on “getting it right”.

If we’re choosing to bodge solutions “for now” and to skimp on quality, we should be honest about that. Sometimes it’s ok. After all, the company doesn’t exist to write tests. But, we need to excercise extreme caution that this doesn’t become the new normal.

Slow is smooth, smooth is fast.

If we slow down, and get it “right” the first time, we won’t have to keep revisiting the same thing. If we don’t have time to do it right, we don’t have time to do it. It’s about prioritizing doing a few things well over doing everything badly.

More Reading

There’s a lot more great information about working with legacy systems in the book: “Working Effectively with Legacy Code” by Michael Feathers. If you have a big system to manage, I’d abhor you to read that.