Tests are a form of waste?

I was in a meeting where a developer said: “every test is a form of waste”. Coincidentally, this meeting was about how the build was taking too long because the tests were slow, so I can see how the connection was made in the mind of the developer. It must be the tests, right?! What a waste (a waste of what actually? Time, money, effort?). However, I think this is a fallacy and I would like to use this blogpost to explain why.

In my career in IT I have heard remarks from some developers in different shapes and forms about how testing is wasteful: it takes too long (“I have spent 3 hours developing the functionality, now I have to spend 6 hours writing tests, how stupid!”) , it is boring, tests are flaky and besides: after all the effort put into making the tests work there are still bugs! Gosh.

Consider the following statement: In essence, with tests we cover (and store) the WHAT of business requirements while the implementation code covers the HOW of business requirements.

I realise that without the implementation code, there is no reason for tests to exist so you could make the argument that the implementation code is also the WHAT of business requirements. However, I hope you agree with me that it is very dangerous and irresponsible to only have an implementation (the how) without storing the requirements of this implementation (the what) in tests. This is one of the reasons why we write tests and why techniques like ATDD, BDD and Specification by Example exist.

What do you think changes more often: the requirement or the code to implement the requirement? Coding standards evolve, programming languages change, developers leave the team, new developers join the team, refactoring is needed to keep the code clean, and so forth.

Of course, requirements change as well; this is one of the hallmarks of agile development. But, in order to implement a change or new requirement more often than not you change existing code as well. So what survives longer? The requirement-covering test, or the code to make sure that the test passes?

Think about that for a minute. Do you still want to make the case that tests are a form of waste?

No, the opposite is true! A test is not waste at all, because a requirement (and therefore, a test) survives longer than the code that implements it.

When you invest in a process like ATDD, BDD or Spec by Example with your team, you will acquire a good base of tests over time. Then, it will actually be easier for you to change the underlying code.

Would you call that a waste? I wouldn’t.