5 ms·

I agree that arbitrary code coverage goals are foolish, but there's a huge benefit that we seem to be glossing over. A good suite of automated tests can double

I agree that arbitrary code coverage goals are foolish, but there's a huge benefit that we seem to be glossing over. A good suite of automated tests can double or triple the productivity of a new team member. Whenever I join a project, I spend the first few months working at half speed or slower because I investigate every dependency before I make a fix or build a new feature. Even working on an unfamiliar part of a big system slows me down as I ask questions and double-check dependencies. Every large team (or team that plans to get large) should consider unit tests to help keep their velocity constant.

dkarl 16y ago
Whenever I join a project, I spend the first few months working at half speed or slower because I investigate every dependency before I make a fix or build a new feature. Even working on an unfamiliar part of a big system slows me down as I ask questions and double-check dependencies. Carelessly changing things you don't understand and expecting the tests to save you does not count as "productivity." Good design decreases the amount you need to know to safely and productively hack on a system. Tests don't. Tests can save an experienced and knowledgeable person from their inevitable mistakes -- they can tell you something is wrong -- but they can't direct you toward the right solution. Someone who doesn't know what they're doing can hack by trial and error until the tests pass, but at that point their code is still likely to be wrong.
Tamerlin 16y ago
So far in my experience, good design does far more to help maintain velocity than tests. In most applications I've been stuck on, the tests ended up being an impediment to development -- because the design was poor. The tests helped to reveal dependencies, so people who were working on bits of code could easily identify what dependencies they had to fix when they made changes, but that also served to underscore how badly coupled the various components were. I guess the moral is that too many mediocre wannabe agilistas try to use testing to cover up bad design.

dkarl 16y ago

Whenever I join a project, I spend the first few months working at half speed or slower because I investigate every dependency before I make a fix or build a new feature. Even working on an unfamiliar part of a big system slows me down as I ask questions and double-check dependencies. Carelessly changing things you don't understand and expecting the tests to save you does not count as "productivity." Good design decreases the amount you need to know to safely and productively hack on a system. Tests don't. Tests can save an experienced and knowledgeable person from their inevitable mistakes -- they can tell you something is wrong -- but they can't direct you toward the right solution. Someone who doesn't know what they're doing can hack by trial and error until the tests pass, but at that point their code is still likely to be wrong.

Tamerlin 16y ago

So far in my experience, good design does far more to help maintain velocity than tests. In most applications I've been stuck on, the tests ended up being an impediment to development -- because the design was poor. The tests helped to reveal dependencies, so people who were working on bits of code could easily identify what dependencies they had to fix when they made changes, but that also served to underscore how badly coupled the various components were. I guess the moral is that too many mediocre wannabe agilistas try to use testing to cover up bad design.