What to do when the testsuite is broken

So you have a suite of unit testskeep-calm-and-unit-test.

Ok, to be honest, they are not all unit tests, some are integration tests.

But hey, you can’t have it all, after all, you’ve almost got a 1000 tests in place, great!

The only downside: when time went by, only two thirds of the test nowadays pass, the rest doesn’t.

The consequence is that nobody runs the tests, and on the build server they don’t run either.

Developers are discouraged to create new tests because they will never be run again.

What to do now?

Basically there are three options:

  1. fix the failing tests;
  2. ignore the failing tests;
  3. delete the failing tests;

The first option is not a real option: who can and wants to fix 300 failing tests?

The second option is tempting: all the code is kept so the remaining unit tests still run and no code is thrown away. And maybe, later, when we have spare time, they all get fixed.

As tempting as the second option is, I choose for the third option: delete all the failing tests. I think all the ignored tests just creates noise in your code, and the spare time to fix them… that will be the day!

And the longer you work on your production code, the more out of sync the testcode will be. So you maybe have to comment out some code in your ignored tests (yikes) in the future to prevent from compile errors.

Yes I understand, removing so much code from your project feels like throwing away money, but I think it will save you money in the future, and you can start right now with a clean base of unit tests.




Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s