Using “Refactoring” as an Excuse to Skip Writing Tests

I caught myself falling into a bad practice this week. I was starting to use the “Refactor” phase of the TDD loop (Write a test, Write code to pass test, Refactor) to implement new code. In the Who’s Working On What code, at the end of May 27th, commit fb9990…, I had just about everything working with just a single project displayed for each engineer.

So the next thing I wanted to implement was to display more than 1 project for (some) engineers. I’d setup the simple structures to allow 2 to be displayed, knowing that at some point I’d need to make this a variable number using an array of projects.

So I erroneously thought to myself, “let’s just refactor the code to use an array instead of fixed properties. I already have a bazillion tests (about 300), so they should catch any issues.

This might have been an ok approach (but not a great one), except it became hard to tell when I started adding new functionality. Luckily, I had chosen to work off of a branch. When it became apparent that what I was doing was wrong, I simply killed the branch and started over. The problem with that approach is that it allows new code to be written (under the guise of “refactoring”) that might not be actually tested. And one of the chief benefits of TDD is that you can be sure that all the code you write is tested.

So, another lesson learned (or “relearned”?). Only write code that the tests compel you to write.

Leave a Reply