About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.May.20 Sat
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.