On the teams I've work on, pushing code that doesn't build and pass all unit tests is grounds for mocking. I have an alias in my zshrc file called "safepush" that runs [clean command] && [build command] && [test command] && git push

If any piece doesn't succeed, the command stops. No push without unit tests passing.

And, as the article points out nicely, this basically prevents people from refactoring their code. In any nontrivial codebase, when you have a lot of tests, then what would have been 15 minutes of work rearranging class structure turns into a whole day of rearranging test cases to fit the architecture again.

It can be, I won't entirely disagree. But it depends how highly coupled your unit tests are to the design.

Unit tests are a safety mechanism- you can easily bog yourself down with too many, tying things up in bad ways, or presuming a specific design. But do you really want to live with no safety at all?

The art, as I see it, lies in writing tests in such a way that you get the guarantees you need, the safety of not letting the next guy (or yourself) screw it all up during later changes while simultaneously not preventing you from doing needed refactoring.

It's a fun challenge.

Exactly what you wrote. That's why I am generally for testing, but I don't buy into Test Driven Development.

In any halfway decent build your tests will run whenever you build the project, to prevent tests from ever getting outdated.

If any test fails, it is because you broke it just now, so you go in and see if your test is broken, or, as is often the case, your refactored code is breaking the expected behaviour of the tested code.

> Unit tests that aren't 100% up to date with the code are worse than no unit tests.

A bit of a tautology... broken code is broken. Unmaintained code, even unit tests, should be deleted.