Interfacing to a Test Tool

The farther you get from direct calls, the more useful some sort of test tool will be in interfacing your tests to your system. The test tool will "know" how to interact with your system at the level you want to interface, and you'll just need to interface the tests to the tool. What this boils down to is writing a different set of methods in the application test class (XTrackTest in our examples) that invoke the code in the system indirectly through the tool, rather than directly by calling them.

We're going to illustrate this by making the executable tests from the previous chapter run through the XTrack user interface (more or less) by interfacing to a Web testing tool called WebART (available at www.oclc.org/webart/downld.htm). This is an HTTP-based tool that interfaces Web-based systems at the same level as a user's browser, allowing us to test almost all the code in XTrack. The only code we'll be missing is what runs in the user's browser JavaScript, for example. As it turns out, XTrack uses very little JavaScript, so this provides pretty good coverage.

WebART isn't the only test tool you could employ for this purpose. Once you understand our approach, you can use it with whatever tool is appropriate for your project.

As we promised, no changes are needed to the executable tests themselves (LoginStoryTest, UserIdStoryTest, TaskStoryTest, and so on). All the activity takes place at the application test class (XTrackTest) and below.

We could create an entirely new version of XTrackTest for interfacing the tests through WebART. This new XTrackTest would have different implementation of the methods login, createUserId, and deleteUserId, and we could swap the two versions of the file in and out, depending on which way we wanted to run the tests.