32.6. Summary In order to test some workflow of RentEz, it was necessary to test through the GUI. Rather than changing the Fit tests to do this explicitly, Emily decided to have the fixtures map from the tests into operations through the user interface. To gain experience with this approach, Emily developed a simple mockup of RentEz for trying out this approach. She ended up introducing a mapping layer, an adapter, so that she could design the desired API for the domain layer in the process. This approach has several advantages. The Fit tests remain independent of the GUI. A change in the GUI may simply require a change in one part of an adapter. By contrast, if the Fit tests are explicitly tested through the GUI, all the affected tests would need to be changed. The GUI can be seen in action, with the possibility of automatically recording the results for user documentation. Simple changes in the application, such as method name changes, are more likely to be picked up at compile time and/or handled automatically through the use of refactoring tools. A portion of the testing can be made through the GUI, tailored to get reasonable build times.
This approach has two disadvantages. The tests are much slower when they go through the GUI. This leads to slower feedback after changes on whether any tests have been broken. The tests are still dependent on the name properties of the Swing components. For example, if a component that is used in an adapter is removed, there is no compile-time check for this; it has to be checked by running the tests.
We take up these matters in the next chapter. Questions & Answers | Q1: | We'd like all our tests to go through the GUI, so that the GUI code is checked as well. | | A1: | There are two assumptions here. One is that the tests will run quickly enough to give you quick feedback. If the build and test process is too slow, people will put off getting essential feedback because of the delays in getting it. One approach here is to run some tests through the GUI and some through the API; the choice can be made randomly when the tests are run, to give the right tradeoff between performance and coverage. The second assumption is that there is significant code in the GUI that needs to be tested along with the functionality of the system. One approach is to reduce the GUI-specific code as much as possible [Fea02]. Another is to have separate tests that simply test that the user interface itself works correctly: that menu items are enabled appropriately, that the right information is displayed, and so on. | | Q2: | It would be great to create Fit tests for an existing system by simply using the system through the user interface. | | A2: | Yes, that can be done by adding code into the system to record the tests at the right level of detail. For example, the code associated with a dialog box could generate an action for a Fit table when the OK button is clicked. This approach is used in texttest [Tex] and is also described in [MBA03]. | | Q3: | What if information that needs to be checked is not available through the GUI? | | A3: | In that case, it will be necessary to change the system under test to log such information when it's changed. Then the Fit test can check the log file for the information. The notion of an adapter, as we introduced earlier, could be used here as well. Rather than encoding details of the log file format in the fixture, an adapter could provide the required API and do this. Then, when the relevant part of the domain layer has a suitable API, that could be used instead. The general approach to using logs for testing is emphasized in the testing framework texttest [Tex]. |
|
