Ever Considered Ditching Your Tests?

At Agile Open Holland, Rob Westgeest proposed a session called "Ditch Your Tests?" I love to challenge assumptions so I joined the conversation to find out if this can ever make sense. Rob kicked off the session by asking us whether, for a stable piece of code, there can ever be valid reasons for throwing away the tests? And if so, why? Rob captured all the reasons we could think of in this mindmap.

It seemed that these things fell into three categories so we annotated the branches with Q, O, and B where:

• Q indicates bad quality tests. These are fragile, hard to maintain or plain stupid tests.
• O indicates tests that are obsolete. These can be ditched because requirements have changed and tests can be deleted along with the code.
• B indicates tests that block us from doing the right thing.

One of our revelations was that once you absorb a TDD mindset, writing tests is your way of learning about what the code does. Reading someone else's tests isn't quite the same and creating that fresh learning. So for complex code, you might choose to go through the process of building the tests again purely to understand it. For example, you might write tests to understand how to use an API. The tests you write can be thrown away, in this instance, as you're not testing that the code that implements the API, these tests simply help you understand how the API can be used.

The conversation got more heated when we got into whether Mock Objects put developers off refactoring. I first started using mocks 10 years ago at Connextra, when there were no tools to support this way of working (see brief history). I recall cases where unpicking the mocks put us off refactoring the code and although there are much better tools nowadays, I'd say mocks do create a small barrier to refactoring. I've also noticed that Mock Objects can sometimes drive teams to write ravioli code where the code is milled down to neat little objects making the larger design harder to see.

So if we have acceptance/system tests that prove the system is working and unit tests are really a design tool then why do we feel nervous about deleting them? Well, the obvious answer is that a good set of unit tests helps us pinpoint bugs and that can save the whole team valuable time. So preserving your design thinking as unit tests has a more practical purpose as well.