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.

Let’s meet in Vienna again – JSFDays 2009

Last years JSFDays in Vienna have been a huge success. The organization was superb and the event definitely focused on JSF. This year the event will be bigger and contains now two tracks. One of them is focused on JSF while the second track has a larger enterprise Java focus. Check out the website.

With JSF 2 on the horizon you definitely should consider making the trip to Vienna. Several of the sessions for JSF will concentrate on that. And who could you tell better about JSF 2 than the guys that shaped it working for the Expert Group. And JSFDays will feature several expert Group members giving you the information from the source.

Let’s meet there and have some fun too. Vienna definitely is a city to enjoy, so consider staying for the weekend as well and discover its many features.

Already booked?

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.

JSF Days 08 – almost over

To all those that forgot to come to Vienna: You definitely missed something really great.

3 days with many important people in the JSF ecospace (Kito: good definition of that) in a very relaxed context. Irian did a great job to organize this second JSFDays in a perfect way, which definitely helps to create this friendly mood.

For those not yet used to be able to get in “touch” with the great names of JSF were pleasently surprised how easy those persons behind the names are. This feature is definitely something I like in the JSF ecosphere. Despite being a difficult environment (todays webapp-development,…) JSF brings along a bunch of nice guys that are very approachable and helpfull. A great community. And this you can really feel here in Vienna at the JSFDays.

Almost a pity those 3 days are almost over… It will be a long time till JSFDays 2009.

The presentations will be available through Irian’s website. As soon as this happens I will report back.

---

I did a presentation on Testing JSF applications and components. Although one of my laptops started to misbehave… it went quite well. I got some nice feedback, questions and hints and wait impatiently for the official feedback analysis.I concentrated on Selenium and JSFUnit.The preparation for this talk are also the reason for the long time since my last post… but it also gave me some input for further posts

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.

Let’s meet in Vienna 2008

What started in 2006 in Munich as a improvised meeting has now it’s official successor. IRIAN Solutions Gmbh organizes the JSFDays 2008 in Vienna.

So let’s meet in Vienna next year in March. See you there.

JSF Usergroup CH – a Special Interest Group of JUGS

Now it’s official the Swiss JSF Usergroup exists. It has been accepted as a SpecialInterestGroup under the JUGS (JavaUserGroupSwitzerland) umbrella.

The next steps will be to organize some presentations for a meeting … to be continued

JSF unit testing alternatives

One of the advantages of JSF is that the application can be written free of references to JSF. All interfacing classes can be pure POJO’s. But if you try to test your own custom-components things get less easy.

OK, you can always test your components in a black-box testing approach. You write a test-webapplication using the component and verify that the rendered code is what you expected. Tools to support this are HtmlUnit, HttpUnit, Selenium, WebTest, and some others. (btw is there a comparision chart listing “all” of those web-app test frameworks?) But this kind of testing is cumbersome and error-prone. Some of the internals of a component cannot be tested at all or are very difficult to test.

What is really needed is some white-box testing framework for JSF. Some are available or should be available soon. So far I have found “Shale Test Framework”, “JSF-extensions test-time” and just recently “JSFUnit”. If you know of other JSF test frameworks, please let me know.

Shale Test Framework is the oldest one. Although it has a dependency on JSF 1.2 the website does not specify whether it provides support for testing JSF 1.2 components/applications.

JSF-Extensions is not so new, but so far no official release has been made. It supports JSF 1.2 and the “test-time” module provides mock objects for most or all JSF 1.2 classes. The source is easy to understand to make private extensions easy.

JSFUnit is the new-comer. They too have not yet done a release, they are too fresh off the press. At this moment you have to check out from svn and then build using maven. JSFUnit is based on Cactus. And I will give it a try in the next few days… stay tuned for more.