In my experience it’s *really* difficult to do agile development (or be agile) without the frequent feedback provided by automated tests. But automated tests can be expensive.
An interesting post on the topic from Elisabeth Hendrickson:
In some contexts, particularly where there is a legacy code base that was created without automated tests, the cost to create and maintain each automated test is extraordinarily high.
Further, the value of those tests is often less than it could be.
The value in any test is in the information that it provides. But when many of the test failures are because the tests, and not the code, are wrong, the information provided by the whole suite of tests is deemed unreliable and untrustworthy. Information only has value to the extent that we can trust it.
Thus, the automated tests in that kind of context are both insanely expensive and low in value. Some years ago this was the norm. In many organizations, sadly, this is still the norm.
But it doesn’t have to be that way.
Successful Agile teams typically follow at least a subset of the XP development practices like TDD and Continuous Integration. Oh, sure, you can be Agile without doing TDD.
But teams that do practice TDD and ATDD wind up with large suites of automated tests as a side effect.
Read the full post here.