If you’re a regular reader of mine, you’ll likely remember, long ago, some time last year, when I brought up a real-world situation about refactoring, that was full of red flags. This is, I think, my fourth delve into this situation… let’s go:

We’ve already estimated the size of these stories, but if we incorporate them into the current sprint and then remove them later (once the coding is completed), it will distort the numbers for the sprint, because the stories cannot be tested yet. Is there a way we can properly acknowledge this work while making it clear that these stories won’t be implemented for a few sprints?

This was actually my first question to the actual person who asked the question: Why can’t these stories be tested yet?

Or more pointedly: Why are you undertaking a refactoring effort, without automated tests in place to validate that the refactoring is indeed a refactoring?

Remember, refactoring, by definition, doesn’t change behavior. So, assuming you have automated tests, you should never need to change these tests to validate a refactoring effort.

This means refactoring should always be an incredibly safe activity. Because your test will always tell you immediately if your refactor changed behavior. Right?

Okay, okay… I know what you’re thinking.

“Yeah, that’s all great if we have automated tests.”

Right. That’s the kicker, isn’t it? If you don’t have automated tests, then you don’t have any assurance that your refactoring is working. So what should you do?

Well, I hope you know the answer. Unless you enjoy the challenge of blind-folded refactoring, which in my experience always has predictable results similar to the aftermath of a blind-folded piñata party, the answer is: Write automated tests.

In this case, this developer is literally looking for work to do, so there’s no excuse here. If his reason for refactoring code that isn’t needed for months is to fill idle time, then that’s absolutely the perfect opportunity to write those automated tests, then refactor.

The alternative… and, sadly, the alternative I believe the team in question opted for, was to go ahead with the refactoring work, without automated tests. What a waste. It’s a waste of the developer’s time, writing code that won’t be used for months. It’s a waste of integration effort whenever that code will be used (and has to be re-merged with a working branch), and a waste of manual testing effort, for something that literally should require no manaul testing effort.