3 ms·

The problem is that unit tests aren't for today. Unit tests are for 3 years from now when you've forgotten how a system behaves and you need to make a major ch

The problem is that unit tests aren't for today. Unit tests are for 3 years from now when you've forgotten how a system behaves and you need to make a major change to it (nb: I'm not talking TDD here). When you get done with that change (and every company I've worked at with no unit tests has), you'll look back and realize you had three choices: 1. Write the unit tests while the code was fresh. Ideally, you wrote well designed unit tests so you didn't have to constantly deal with maintaining crappy test code. Unfortunately, most test code doesn't seem to be well-written, DRY code, so you spend a lot of time in the interum maintaining it. 2. Figure the code out again when you need to change it (likely somebody else is doing the figuring out by then) and write unit tests that show current behavior. The "figuring out" step is always nastier than you expect. 3. Start digging and hope you come out the other side with something reasonably similar to what you started with. The trick is figuring out which one optimizes best for your business. Pinboard might be able to get away with #3. Air traffic control may have no choice but to be #2 (did people write unit tests way back then? I know I didn't write any unit tests on my Atari 600 in '83 :).

arethuza 16y ago
On point 2 - I tend to find that if I write unit tests at the same time as I write code then the code is structured to be easier to unit test. Writing unit tests for code that has been developed without any concerns for unit testing can be a complete nightmare.
- Erikagd77 16y ago
  It is true that unit testing code that was not designed for testing can be difficult, but it is certainly possible. Java reflection can set data values in private fields for times when the original class did not include a setter method for testing. Commerical solutions, like http://tinyurl.com/4rabnef http://tinyurl.com/4rabnef, provide stubbing frameworks to replace method calls at runtime and inject test data without rewriting the original code.
ekidd 16y ago
The problem is that unit tests aren't for today. My unit tests are half for today—they actually let me code faster and better—and half for next month, when I discover a much better way to do things and reorganize my code savagely. 3 years from now? That's just a bonus which lets me feel smug. The real payoff was immediate, and did not involve any virtuous self-discipline.

arethuza 16y ago

On point 2 - I tend to find that if I write unit tests at the same time as I write code then the code is structured to be easier to unit test. Writing unit tests for code that has been developed without any concerns for unit testing can be a complete nightmare.

Erikagd77 16y ago
It is true that unit testing code that was not designed for testing can be difficult, but it is certainly possible. Java reflection can set data values in private fields for times when the original class did not include a setter method for testing. Commerical solutions, like http://tinyurl.com/4rabnef http://tinyurl.com/4rabnef, provide stubbing frameworks to replace method calls at runtime and inject test data without rewriting the original code.

ekidd 16y ago

The problem is that unit tests aren't for today. My unit tests are half for today—they actually let me code faster and better—and half for next month, when I discover a much better way to do things and reorganize my code savagely. 3 years from now? That's just a bonus which lets me feel smug. The real payoff was immediate, and did not involve any virtuous self-discipline.