This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: False Dichotomy Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

On the Agile Testing mailing list, in a response to the never-ending debate discussion of "Manual Testing versus Automated Testing" Ron Jeffries has finally pinned down the false dichotomy at the heart of that debate:

The only time not to automate a test ought to be if we are never going to want to run it again. But it isn't. The more common time we don't automate a test is because it would be "too hard" to automate it. That is, however, not really a property of the test, though we like to put it that way. It's really a property of our own test automation capability and tools.

This is also the difference between unit testing and testing via the debugger. If you or some other programmer is ever going to modify that code you just wrote and tested via the debugger, you will save time overall by writing a unit test to do that re-testing automatically. (Even better, TDD it.)

As Ron points out, our tools are too difficult. If manually testing the app created automatically re-usable tests that didn't break or get confused by minor changes in UI, that would be great, but few if any teams have that capability.

It can be very difficult to get legacy code under test. "RetroFITting" FIT tests into a legacy app can be extremely hard. (Christopher McMahon appears to have coined RetroFITting) So we forgo automated tests because of the expense, and repeatedly "run" manual tests. And in iterative development, you need to repeatedly test to make sure nothing previously shown to be working has stopped working.

XP makes creating automated tests a high priority because otherwise, in practice, automated tests don't get done at all. And then the expense of repeating tests manually will turn an agile project into a waterfall one.