Jazoon 2010 – Testing-related Talks

Jazoon 2010 is history. What remains is the surprise in the eyes of the speakers of the two testing related talks: Full house, one talk had all the seats occupied and the other almost, just a few seats remained empty. Seems like testing gets more attention.


JadeLiquid first impressions

Time to test another testing tool. This time I’ll try to give a commercial tool possibility to convince me: LiquidTest – Agile Functional Testing

The first installation attempt did fail, because the license key sent by mail was distorted by some element in the mail-chain. A call or an email will supply you with a test-file with a working license key.
Once the eclipse plugin is installed and the license activated, you will find a new eclipse perspective and a sample project with the usual test-sample (a call to a famous search engine). Another nice touch is the creation of a new test-class. The plugin immediately offers to enter “record mode”…

to be continued


JSFUnit 1.0.0.GA available

According to the projects website JSFUnit has gone live with release 1.0.0.
Time to get serious about JSF unit testing again.


JUnit-testing BigDecimals: watch your JUnit version

Consider this test:

  public void testBigDecimalAssertEquals() {
    BigDecimal number1 = new BigDecimal("0.01");
    BigDecimal number2 = new BigDecimal("0.99");

    System.out.println("number1.equals(number2)= " + number1.equals(number2));
    assertEquals(number1, number2);
    System.out.println("  but JUnit thinks its equals...");
    assertTrue(number1.equals(number2));
    System.out.println(  "  only testing for BigDecimal.equals() == "
                       + "true will yield the correct result.");
  }

I definitely expected the assertEquals condition to report a failure, but…

In my Eclipse environment I had JUnit 4.3.1 loaded and the test only failed on the assertTrue condition.

After some download- and debug-sessions I learned that some JUnit-versions (> 3.8.x and < 4.4) had some code in the Assert.isEquals() method which caused this behaviour:

private static boolean isEquals(Object expected, Object actual) {
  if (expected instanceof Number && actual instanceof Number)
    return ((Number) expected).longValue() == ((Number) actual).longValue();
  return expected.equals(actual);
}

Versions before and after 4.4 do not check for a Number-instance, they just call the objects equals method.


Jazoon 08 looming ahead

Time for the next big Java conference… the Jazoon 08.

I’m gonna talk about JSFUnit. It will be an introduction to this JSF testing framework (presentation info).

Hope to see you there and have a chat together… my company’s (Credit Suisse) booth seem to e close Netcetera’s, let’s hope their coffee is as great as last year (was a really good coffee, even by italian standards). From our coordinator I heard, that we will distribute our good chocolate goodies… That should make a good combo: good coffe and good chocolate.


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;
}