Tim Gifford

On the last project I rolled off from, we developed a framework that allowed the business users to write the fit tests in Excel spreadsheets. We wrote a component that would run and execute fit using the excel spreadsheets as input. This worked great as it allowed the customers to write the fit tests for us. When they needed more descriptive capabilities in their "tests" we would extend the framework as necessary. Of course writing the tests is one thing, but for each new "fixture" in a fit test, a new class has to be written to handle the fixture. You end up with a bunch of reusable fixtures that the clients become accustomed to and compose together to create more complicated tests. At the end of the day, it was just delegating to fit, so it was pretty simple. On our "big bertha build" fit ran as part of the cruise control build. Of course, before a checkin, all developers had to run the fit tests on their local machine to ensure that they had not messed up any functionality. As far as debugging, if you actually had to spend time in the debugger, you could attach yourself to the fit process, set a breakpoint and let it run. More often than not, we just logged like crazy, as it was a much more efficient debug tool. On our big build, we also ran WATIR tests to exercise the UI. This ensured that we had full coverage from UI all the way to mapping.