Section 32.1. Introduction


32.1. Introduction

In Chapter 14, Don, Emily, and Sarah started to develop several Fit tables for testing workflow. Here, we see how Emily proceeded to write fixtures that connect those Fit tables to the system under test, even though those tables were developed further in Chapter 15.

Unfortunately, the RentEz software architecture is structured poorly; the GUI code and the business logicthe presentation and domain layersare tangled.[1] So there is no clear domain layer with an API that can be tested directly. Emily considered several approaches, with prompting, to tackle this difficulty.

[1] The three layers are introduced in Section 30.3 on p. 256.

"We could rewrite the Fit tests, using a scripting language that tests explicitly through the GUI. However, this doesn't allow us to make much progress and we end up with tests that are difficult to maintain (see the following Note).

"We could write Fit fixtures that generate scripted tests instead of testing immediately. This approach is reasonable as our testers are already familiar with a scripting toolif they wish to continue using it. Any changes can then be made to the Fit tables rather than to the test scripts, improving maintenance. However, this approach doesn't use the reporting capability of Fit, as the generated test scripts are run separately to get feedback.

"We could rewrite the Fit tests so that they explicitly operate on the user interface. As with the first alternative, this would lead to maintenance difficulties and would complicate the tests with irrelevant, and potentially unstable, details.

"We could leave the tests in their current abstract form and change the application to expose the parts of the domain layer that are needed for those tests. We could do this in small steps, slowly getting the tests going and checking manually that the system hasn't been broken. But this means lots of manual testing to ensure that the effort in untangling the presentation and domain layers hasn't introduced errors.

"We could leave the tests in their current form and have the fixtures perform operations on the GUI. This means that the Fit tests remain concise and independent of the details of the GUI."

Note

Tests in many scripting languages can be recorded when the system is used and can be played back at another time. Unfortunately, the resulting test scripts are usually far too detailed and are difficult to alter and maintain. Some suffer from depending on the position of GUI components on the screen, so are vulnerable to simple layout changes.


The company had used various test scripting systems but was not inclined to continue with them. After much discussion, Emily decided to proceed with the last option. To get started on this approach, she decided to try it out on a simple system.

The RentEz GUI is written with Java Swing, so a way was needed to test through that interface. Fortunately, there are several open source tools for automating unit testing of Swing-based GUI systems. See the following Note for details of some of these tools.

After exploring the various tool possibilities and seeking advice, Emily decided to use jfcunit. This tool is intended for unit testing, based on JUnit, so Emily used a FitLibrary class that made it easy to use from Fit fixtures.

Note

Following are several open source frameworks for unit testing Java Swing-based GUI systems:[a]

[a] See the Gui Tools at www.junit.org for the latest list.

  • Abbot, available at http://abbot.sourceforge.net

  • jfcunit, available at http://sourceforge.net/projects/jfcunit

  • Jemmy, available at http://jemmy.netbeans.org

  • Pounder, available at http://pounder.sourceforge.net

  • Marathon, available at http://marathonman.sourceforge.net

Several of these frameworks also have support for scripting tests in various forms, including using XML. Similar frameworks are available for other GUI systems.

Such systems have support for accessing the required component from the GUI and operating on it. Access to a component may be made in various ways, including its name property and its type.




    Fit for Developing Software. Framework for Integrated Tests
    Fit for Developing Software: Framework for Integrated Tests
    ISBN: 0321269349
    EAN: 2147483647
    Year: 2005
    Pages: 331

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net