Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should failing tests make the continuous build fail?

If one has a project that has tests that are executed as part of the build procedure on a build machine, if a set tests fail, should the entire build fail?
What are the things one should consider when answering that question? Does it matter which tests are failing?


Background information that prompted this question:

Currently I am working on a project that has NUnit tests that are done as part of the build procedure and are executed on our cruise control .net build machine.

The project used to be setup so that if any tests fail, the build fails. The reasoning being if the tests fail, that means the product is not working/not complete/it is a failure of a project, and hence the build should fail.

We have added some tests that although they fail, they are not crucial to the project (see below for more details). So if those tests fail, the project is not a complete failure, and we would still want it to build.

One of the tests that passes verifies that incorrect arguments result in an exception, but the test does not pass is the one that checks that all the allowed arguments do not result in an exception. So the class rejects all invalid cases, but also some valid ones. This is not a problem for the project, since the rejected valid arguments are fringe cases, on which the application will not rely.

like image 842
earlNameless Avatar asked Jan 30 '09 13:01

earlNameless


1 Answers

If it's in any way doable, then do it. It greatly reduces the broken-window-problem:

In a system with no (visible) flaws, introducing a small flaw is usually seen as a very bad idea. So if you've got a project with a green status (no unit test fails) and you introduce the first failing test, then you (and/or your peers) will be motivated to fix the problem.

If, on the other side, there are known-failing tests, then adding just another broken test is seen as keeping the status-quo.

Therefore you should always strive to keep all tests running (and not just "most of them"). And treating every single failing test as reason for failing the build goes a long way towards that goal.

like image 51
Joachim Sauer Avatar answered Sep 28 '22 06:09

Joachim Sauer