Today’s short idea is: before you hardcode a value or comment something out for debugging purposes, write a test that ensures that you change it back. This way you break the build if you commit the change.

The thought here is that if the functionality is actually important, there should probably be a test for it.

Of course, it is useful to weigh the long-term costs of maintaining a test like this. There are other stages in your process that can also catch these sorts of defects, including:

• inspecting your diff before committing (git diff and git diff --cached)
• incrementally staging changes (git add -p)
• doing code reviews (still not foolproof!)
• having other tests that detect the change
• making small changesets to make the change easier to spot
• having smoke tests or business metric tests

It may be useful to write the test and then remove it once your small change is reverted. If this test is the only one that fails when you change an important configuration setting or code value, it might indicate that there was initially a useful test missing.