Every large team (or team that plans to get large) should consider unit tests to help keep their velocity constant.
Every large team (or team that plans to get large) should consider unit tests to help keep their velocity constant.
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.
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.