The Disco Blog

As a deacon of developer testing, I found my programming pilgrimage into the realm of TestNG-Abbot quite hip (and you thought I’d use another ecclesiastical word– this is the disco blog, man!). As the current documentation is rather sparse, here are four easy steps to TestNG-Abbot bliss-ness:

1. First download the current version of TestNG-Abbot, which right now is 0.2. Keep in mind, that this hip version was built using Java 5; accordingly, if you’d like to use this framework, you’ll also be required to run on Java 5.
2. Then download the current version of Abbot, which is 1.0.0.rc5. TestNG-Abbot is essentially a wrapper for the copasetic Abbot framework and thus delegates a lot of the work to it. It is important to use this version of Abbot as this is what TestNG-Abbot assumes.
3. Of course, TestNG-Abbot also was designed to be utilized in concert with TestNG; consequently, you’ll need at least TestNG version 5.4. As of right now, the current version of TestNG is 5.5; however, I’ve only tried out things with 5.4.
   • If you want to use the TestNG Eclipse plugin, I’ve got things working with version 5.4.0.0 and it isn’t clear to me which version of TestNG it assumes but my best guess is that it’s following the same versioning scheme as TestNG.
4. Write a test that employs TestNG-Abbot’s disco AbbotFixture class in concert with it’s GUI component fixture classes, which makes the process of GUI testing quite simple.

Now you’re ready to become a full fledged clergyman– but before you drift into verification veniality with TestNG-Abbot, let me share with you some thoughts.

Keep in mind that in order to actually test a smokin’ GUI, you’ll need a way to create an instance of the GUI that is some descendent of java.awt.Window. While this may seem like common sense, I’ve thus far run into a few different GUIs that either extend from JPanel or are boot strapped via a heavy main method.

If you have challenges with GUI initialization, you may need to specify the dimensions of the GUI explicitly to the AbbotFixture– for example, if you find that when you start running tests that the only thing that pops up is a tinny little GUI, force the GUI’s size via the overloaded showWindow method.

One particularly hip feature of TestNG-Abbot is its collection of GUI fixture classes, which, when used in concert with the AbbotFixture class, make the testing process simple– all you need to do to employ these handy classes is specify the component’s name and your desired behavior and the fixture class handles the rest. Plus, if you’d like to assert certain behavior, the fixture classes have a series of validation methods, which start with should.

For example, below is some code that creates a JTextField for use in a GUI. Note how the JTextField instance is named widgetName. It is this logical name by which you can obtain a handle to this object via the Abbot framework.

private JTextField getWidgetName() {
 if (widgetName == null) {
  widgetName = new JTextField();
  widgetName.setName("widgetName");
  widgetName.setBounds(new Rectangle(109, 20, 71, 26));
 }
 return widgetName;
}

Once you have a handle to a GUI component, you can programmatically change it– like in my case, because it’s my bag baby, I can add text to it via TestNG-Abbot’s TextComponentFixture object like so:

TextComponentFixture text1 = new TextComponentFixture(this.fixture, "widgetName");
text1.enterText("Cab01-21");

In GUIs (and also web applications), the easiest way to verify if things are working correctly is to assert the presence of precise text after some known copasetic event. Consequently, with TestNG-Abbot’s fixture classes, you can assert that a dialog shouldBeModal or that a label displays certain text with the LabelFixture’s shouldHaveThisText method. For example, I can verify that a certain label displays some status text after a click a button:

ButtonFixture bfix = new ButtonFixture(this.fixture, "widgetCreate");
bfix.click();

LabelFixture fix = new LabelFixture(this.fixture, "statusLabel");
fix.shouldHaveThisText("Widget price isn't valid");    

One thing to remember as you write GUI focused tests– changes to the GUI will affect your hip tests and you may not realize it until runtime due to the logical matching of names (note how the names are Strings, man). This is the same issue that affects web tests too, by the way. Abbot’s matching of names, however, is much more robust that positional matching that some frameworks of old utilized.

As you can see, becoming a vicar of GUI validation isn’t too challenging with the nifty combination of the Abbot framework hitched up with the caste and revered…errr, I mean the copasetic and tripping TestNG. Dig it?

Trackback this Post | Feed on comments to this Post