How To Step By Step

• Learn how it works. Study the examples on the web site. Take the CooksTour. Programmers should read the code to understand the interactions between Parse, Fixture and TypeAdapter. Testers should compare Row-, Column- and ActionFixtures. Try putting some of our examples on your own server and see if you can get our run.cgi to fetch and run them. Change them around to see what happens.

• Smoke-test at home. DownloadNow and see if our examples work on your machine. Pick a small program in your environment and see if you can hook a fixture up to it. Don't be afraid to run a test against a half-done fixture, or even a just started fixture. (See MakingFixtures.) This should be easy. If it isn't, try hooking into different objects or try some application that launches a different way. Start with something easy and work to harder examples.

• Run a pilot project. Find some functionality in your current work that seems easy to describe with tables. Pick something that is bigger than easily unit tested, but not much bigger. Write some tests that will be easy to pass. Then pass them. Now see if you can make the tests harder without changing the fixtures much. See if you can hook the fixtures into different levels of your system. Bring programmers, testers and customers together to review the pilot. Take every suggestion and try it in a small way.

• Choose a repository. This can be anything that saves, reads and writes html, which is just about everything. But some things work better than others. Choose tools that all parties know or are willing to learn. Microsoft Word is a good choice. Create a shared space to keep documents. A share with subdirectories for each iteration might be fine. Draft rules, roles, workflow and lifecycle for these documents. Make this fit on one page. Setup small test databases.

• Run in development. Hook up developmental machines. Make it easy to run any test, past or present, on just compiled code. (See MakingRunners.) Make it easy to add or edit tests while developing. Try pair-programming with a tester or customer, they may have a great instinct for interpreting failures and sequencing work.

• Run in build. Automatically run all accumulated tests against each build. If this takes too long, just run this iteration's tests with the build and run regressions on another machine. Post reports by build number. Collect statistics. Plot these automatically.

• Run in QA. Test with and without the framework. Explore each release independent of the framework, but try exhibiting discoveries within it. Try including test tables in bug reports. Make sure the build and configuration information is included in reports automatically. Set up a test farm that can run tests you've just written against multiple builds on multiple platforms.

• Share your experience. Tell us what worked well and what didn't. Let us distribute sample test results, appropriately sanitized of course, and your fixturing tips. Let your vendors know you want this testing to be even easier with their next release. Ask them to provide fixtures into their runtime environments. This is especially important for application engine vendors. Think about larger testing issues and how this framework fits in to them. Try original things. Advance the art.

Variations on a theme? What worked for you?