Simple walkthrough testcase using SeleniumTestCase

After all the preparations its time to write some tests. Imagine a sample-application that contains a page per component from a component set. For our nightly build we want to know whether all pages work. So a first test would be to use the browser and click through all pages. Annoying and always the same. Calls for an automated test, doesn’t it?

@Test public void checkCatalog() {
  openAndWaitWebAppRoot();
  clickAndWait("link=CATALOG");
  assertPageTitleEquals("JSF Components Catalog");
  clickAndWait("link=CATALOG");
  clickAndWait("link=Layout components");
  assertPageTitleEquals("Layout components");
  clickAndWait("link=Layout");
  assertPageTitleEquals("Layout Component");
  clickAndWait("link=Container");
  assertPageTitleEquals("Container Configurator");
  clickAndWait("link=GroupBox");
  assertPageTitleEquals("GroupBox Component");
  clickAndWait("link=Tabbed Pane");
  assertPageTitleEquals("TabbedPane Component");
  clickAndWait("link=MessageArea");
  assertPageTitleEquals("MessagesArea Component");
};

Looks easy, doesn’t it? Looks and feels just like the instructions for a human tester. And that’s the writing test should be: simple.

Such a test can also survive a revamp of the menu-structure of the application, as long as the texts of the menu-items remain constant, the testcase, just like the human tester, still find the links to click on. Was very usefull when we did such a refactoring of the sample-application. Every now and then someone from teh team would do the “cvs update”-redeploy-”let the testuite run”-cycle and just report which areas needed some massaging.

New tricks for SeleniumControl and SeleniumTestCase

Since the original post introducing SeleniumControl and SeleniumTestCase these two classes learned some more tricks.

The most annoying thing I noticed about that code was, that I had to trigger the SeleniumTestSuite to be able to run a testcase. So I added a simple method to SeleniumControl (isStarted() returning true if server != null) to allow a testcase to query for that and, in case of need, to start the SeleniumServer on its own. The TestCase class checks for this in its setupBeforeClass()-method…

Now I can start either a SeleniumTestSuite, which results in the server started only once for the whole testsuite, or a SeleniumTestCase, which starts the server just for that single testcase. At the beginning the restriction did not hurt, only with the evolution of the test-suite (about 125 tests so far…) this started to itch.

After a few testcases I also added a method to SeleniumTestCase to open the web-applications root:

public boolean openAndWaitWebAppRoot() {
boolean result = false;
try {
selenium.open(getWebAppRoot());
selenium.waitForPageToLoad(pageTimeOut);
result = true;
} catch (Throwable t) {
result = false;
System.err.println("--- received an exception: " + t);
}

return result;
}

public String getWebAppRoot() {
return testHost + testAppl;
}

Preparing your JSF webapp for testing

Be it load&performance testing, be it unit-testing, it seems that all related tools have some problems with JSF’s dynamic ID-attributes.

With dynamic ID I want to indicate that the ID of a certain input-field or a button/link can change if

• no fixed id is specified (id=…)
• the page-structure changes (eg. conditionally rendered components in templates)
• real page-changes (new requirements, refactorings)

I would say a testable JSF web-application has fixed ID’s for all input- and command-components. Pure output-components like h:outputText do not need a fixed ID.

So far this is the most important testability-criteria. Of course most things can be done otherwise. But it sure is more hassle. The load&performance test-tools are more dependent on the ID-attribute because it determines also the NAME-attribute. I consider the better testability more important than the minimal time-saving by not specifying the ID-attribute.

Selenium Toolkit (preparing to write Selenium Tests)

What should you prepare when you want to write Selenium Tests in the form of Java JUnit tests?

I found that a few tools and urls can help to save your hair from getting too white:

• FireFox as the Browser with these plugins:
  • Xpather (homepage, extension)
  • FireBug (homepage, extension)
• XPath
  • XPath Tutorial Helpfull introduction into XPath
• Selenium
  • Selenium RemoteControl Has also subpages for Java
• IDE
  • Every IDE with JUnit-support is better than nothing, so just use your preferred IDE, as long as it has JUnit support.