4 ms·

It depends what you're developing, and who you're developing with. If you're developing something which must work 100% every time or else someone will die, the

It depends what you're developing, and who you're developing with. If you're developing something which must work 100% every time or else someone will die, then unit tests are a must. If you're developing with people who break the build all the time, then unit tests are useful. Unit tests that aren't 100% up to date with the code are worse than no unit tests.

emddudley 11y ago
> 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.
mabbo 11y ago
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.
- TeMPOraL 11y ago
  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.
  - mabbo 11y ago
    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.
    - TeMPOraL 11y ago
      Exactly what you wrote. That's why I am generally for testing, but I don't buy into Test Driven Development.
Freak_NL 11y ago
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.

emddudley 11y ago

> 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.

mabbo 11y ago

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.

TeMPOraL 11y ago
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.
- mabbo 11y ago
  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.
  - TeMPOraL 11y ago
    Exactly what you wrote. That's why I am generally for testing, but I don't buy into Test Driven Development.

Freak_NL 11y ago

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.