Summary

• Automation on an XP project starts with writing executable tests immediately, not waiting for the system to be built and then capturing script, as with traditional test automation.

• Tests written this way fall into modules that naturally encapsulate system functions and relate directly to features being tested.

• The parameterization of the modules of tests written this way is obvious and allows the tests to be independent of particular test case values, making it easy to add to, change, and reorganize things when the customer changes her mind.

• The main thing you want to know when a test runs is whether it passed or failed, and you don't want to have to dig through test output to find out.

• The basic problem with the baseline comparison method is that it starts with the assumption that everything is equally important.

• Instead of spending effort on trying to ignore what's unimportant, focus on the critical things that determine if the function worked correctly.

It's hard to understand all these concepts when you're just reading about them. Working through the following exercise (or at least reading through our proposed answer) will help you see what we're talking about.