At this point, if you’re still with me after four posts on the subject, you may wonder:
How the hell does any change ever happen?
How does any codebase ever get better?
That’s a fair question, and if we’re all putting on our big boy sweatpants and being frank with each other; it’s really hard.
Why would I do all of this ?
Why would I:
- Figure out the part of the codebase that life would be great if I could get past these unit tests that are hard to write and have questionable value
- Figure out that part’s cyclomatic complexity
- Figure out whether its value is visible or invisible to business stakeholders
- Try to sell changing that module to the business
Today, we’re going to talk about the final part, putting everything together.
At this point, you are ready to dive into the code and make changes.
I’d recommend, if this is the path you’re intent to go down, to write characterization tests to fully understand what the bits are doing. That is an entire series unto itself; so I won’t cover it here, but the idea is to write a test against the outermost public API for the thing you’re touching (warts and all) and have that series of tests help you understand what’s at play when you make a change.
You should also write contract tests that ensure the shape of data you’re sending to the database or to the user doesn’t change.
And then you dive in. The book Refactoring by Martin Fowler is useful here; as it details step by step what to do in a given situation. You start to put parts under test and factor out changes, and you do it, again and again.
But those are the technical steps that come at the long end of the steps I mentioned above; and those steps I mentioned above are important.
For what? Why would I do all that?
Well, to be blunt: If you’re not developing software through TDD, this is the road you’re on for the rest of your career.
You’re on a never-ending cycle of pain in your codebase, using metrics like cyclomatic complexity to triage issues (as well as whether it visible or invisible, and who it affects), and trying to sell change to your business.
That’s going to be your life.
Inertia doesn’t just apply to physics; it also applies to making change, especially change to codebases that are working and in production.
The appetite for something breaking is very low, and the unforseen benefits of refactoring a module are too hard to quantify to get over that hurdle.
In short, if you work at a median company doing median work, the deck is stacked against you.
It is a much larger subject than one post can do justice to (or even 100 posts), but the art of selling the need to change is crucial to being able to improve your codebase if you make tests an afterthought.
The short question is: Do you want the pain associated with writing tests after? Do you want to go through these steps for the rest of your career?
If not, you have two choices: Adopt TDD, or ignore unit tests entirely.