DEV Community

Jonathan Hall
Jonathan Hall

Posted on • Originally published at jhall.io on

What to do with broken tests

Imagine you’ve just started a new job or joined a new team. They have a working product, that’s already used in production by a large number of active users, but the code looks like a big pot of grandma’s spaghetti, complete with tomato sauce and meatballs.

This describes the majority of projects I’ve joined, so I expect you’ve run into something similar before, too.

Now further imagine that this project has a bunch of automated tests written, but they aren’t run regularly. Perhaps because they take too long (hours?), or perhaps simply because nobody took the time to set up a build server and CI pipeline to run the tests automatically.

Whatever the reason for the test disarray, how should you proceed, if your goal is to start receiving value from these tests again?

Below is my suggested approach, which I have used successfully on several projects:

  1. Disable broken tests.

  2. Automate your tests.

  3. Fix broken tests.

  4. Delete broken tests.

  5. Write tests for all functionality changes.


If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.

Top comments (0)