Our team is having a heated debate as to whether we allow failing unit tests to be checked-in to source control.
On one side the argument is that yes you can as long as it is temporary – to be resolved within the current sprint. Some say even that in the case of bugs that may not be corrected within the current sprint we can check-in a corresponding failing test.
The other side of the argument is that those tests, if they are checked-in must be marked with the Ignore attribute – the reasoning being that the nightly build should not serve as a TODO list for a developer.
The problem with Ignore attribute however is that we tend to forget about the tests.
Does the community have any advice for us ?
We are a team of 8 developers, with a nightly build. Personally I am trying to practice TDD but the team tends to write unit tests after the code is written
I’d say not only should you not check in new failing tests, you should disable your “10 or so long-term failing tests”. Better to fix them, of course, but between having a failing build every night and having every included test passing (with some excluded) – you’re better off green. As things stand now, when you change something that causes a new failure in your existing suite of tests, you’re pretty likely to miss it.
Disable the failing tests and enter a ticket for each of them; that way you’ll get to it. You’ll feel a lot better about your automated build system, too.