WebTest is in fact “only” a set of Ant tasks therefore it’s not a surprise that WebTest tests are traditionally written in XML. Grails WebTest plugin has shown that Groovy can be a very pleasant alternative thanks to the AntBuilder. Even if you don’t use Grails, you can write WebTest tests in Groovy using the support provided by WebTest’s distribution but if you plan to write all your tests in Groovy, this is surely not optimal. This post shows step by step a way to write WebTest tests that is near to a traditional setup for unit tests using Groovy and Maven.

Note: I’m not a Maven expert. The proposed code works but it can perhaps be improved.

1. Create a new Maven project

   mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=my.domain -DartifactId=myWebTestApp
   

2. Edit the generated pom.xml
   1. Add WebTest as dependency:

          <dependencies>
              ...
              <dependency>
                  <groupId>com.canoo.webtest</groupId>
                  <artifactId>webtest</artifactId>
                  <version>3.1-SNAPSHOT</version>
              </dependency>
          </dependencies>
      

   2. Add reference to WebTest’s Maven snapshot repository

      	    <repositories>
      	        <repository>
      	            <id>webtest_dependencies_snapshot</id>
      	            <name>WebTest dependencies</name>
      	            <url>http://webtest.canoo.com/webtest/m2-repo-snapshots</url>
      	        </repository>
      	    </repositories>
      

      Note that this is needed only if you want to use the latest WebTest snapshot (which is always the best one). You don’t need it if you use a version that is available on the central repository. As of Apr. 30, WebTest 3.0 has not been uploaded to the central repository. The upload request is available here: MAVENUPLOAD-2439.

      Update: WebTest 3.0 is available in Maven central repository since May 19.

   3. Configure the GMaven plugin

      <build>
      	<plugins>
      		<plugin>
      			<groupId>org.codehaus.groovy.maven
      			</groupId>
      			<artifactId>gmaven-plugin</artifactId>
      			<version>1.0-rc-5</version>
      			<executions>
      				<execution>
      					<goals>
      						<goal>compile</goal>
      						<goal>testCompile</goal>
      					</goals>
      				</execution>
      			</executions>
      		</plugin>
      		<plugin>
      			<groupId>org.codehaus.mojo</groupId>
      			<artifactId>build-helper-maven-plugin</artifactId>
      			<executions>
      				<execution>
      					<id>add-test-source</id>
      					<phase>generate-sources</phase>
      					<goals>
      						<goal>add-test-source</goal>
      					</goals>
      					<configuration>
      						<sources>
      							<source>src/test/groovy</source>
      						</sources>
      					</configuration>
      				</execution>
      			</executions>
      		</plugin>
      	</plugins>
      </build>
      

3. Create the Eclipse project

   mvn -Declipse.downloadSources=true eclipse:eclipse
   

   I guess that something similar exists for other IDEs.

4. Import the project in your workspace
5. Add Groovy support in the IDE
   The Groovy support in Eclipse is not as good as in other IDEs but it is better than nothing.
6. Write your first WebTest in Groovy src/test/groovy/my/domain/FirstWebTest.groovy

   package my.domain
   
   import com.canoo.webtest.WebtestCase
   
   /**
    * My first WebTest in Groovy.
    */
   class FirstWebTest extends WebtestCase {
   
   	void testGoogleSearch() {
   		webtest("My first test") {
   			invoke "http://www.google.com/ncr", description: "Go to Google (in English)"
   			verifyTitle "Google"
   			setInputField name: "q", value: "WebTest"
   			clickButton "I'm Feeling Lucky"
   			verifyTitle "Canoo WebTest"
   		}
   	}
   }
   

7. Run the test
   • As normal unit test from the IDE
     As it is a normal unit test and you can use the IDE support for that. In Eclipse this can be done with right mouse click / Run As... / Junit Test or with the shortcut Alt + Shift + X Z
   • Or from the command line

     mvn test
     

8. Enjoy the results!
   Running a WebTest this way produces “normal” JUnit reports as well as the traditional reports of WebTest that contain precise information to quickly find the cause of failed tests.
9. (optional) Run headless
   Per default WebTest shows a console that informs about the running tests and opens the reports in your browser once the tests are finished. This is often useful on a workstation but it may be really annoying on a build server. To avoid that, you just need to set the wt.headless property:

   mvn test -Dwt.headless
   

The 4th edition of the Free Open Source Conference (in short FrOSCon) in Sankt Augustin (near to Bonn, Germany) will take place on 22. and 23. August 2009.

This year I’m involved in the organization of a small part of the event: the Java sub conference. If you have some interesting topic(s) that you want to present around Java and Open Source, don’t wait any longer, go to the Call for Paper site and submit your proposal.

The HtmlUnit team is pleased to announce the release of HtmlUnit 2.5. This release brings another round of improvements and bug fixes.

Here is an extract of the change log:

• improved JS support, particularly full support for MooTools
• repackaged Rhino classes to allow to use HtmlUnit and a regular Rhino version in the same project
• experimental WebClient.waitForBackgroundJavaScript() and WebClient.waitForBackgroundJavaScriptStartingBefore() for simple, fast and deterministic AJAX testing
• reworked handling of background JS tasks using JDK5 executors
• …

Download: http://sourceforge.net/project/showfiles.php?group_id=47038

Great news: the proposal of HtmlUnit committers Daniel Gredler and Ahmed Ashour for the next JavaOne conference has been accepted!

They will present ” HtmlUnit: An Efficient Approach to Testing Web Applications ” at the biggest Java conference in San Francisco (May 31 – June 05).

This is an additional very good sign for the constantly growing recognition of HtmlUnit and I hope that it will be the occasion for them to meet a lot of HtmlUnit users.

Should HtmlUnit move to Apache Foundation? (the first step would be to make a proposal for the Apache Incubator)

Nothing is decided, we’re just thinking loud and are interested to hear what our users think of this idea. I’ve started the discussion in HtmlUnit user mailing list but comments are welcome here too.

I will present “HtmlUnit: An Efficient Approach to Testing Web Applications” together with Daniel Gredler at TheServerSide Java Symposium in Las Vegas (March, 18).

This will be funny because I work together with Daniel in the HtmlUnit project since a few years and I’ve never met him until now.

I think that this will be a great occasion to show HtmlUnit’s potential and I hope that we will meet a lot of HtmlUnit users.

Thanks to Tools & Techniques chair Frank Cohen for inviting us.

The HtmlUnit project is pleased to announce the availability of the HtmlUnit 2.4 release.
This release brings another round of improvements and bug fixes. This should have been a Christmas relase but a regression found in NekoHtml-1.10 forced us to wait a bit.

Here is an extract of the change log:

• improved JS support, particularly full support for the AJAX libraries JQuery and MochiKit
• possibility to use real ActiveX objects (on windows only)
• minimal applet support
• support for IE conditional comments
• …

Download: http://sourceforge.net/project/showfiles.php?group_id=47038

Enjoy!

Upcoming release 2.4 of HtmlUnit will provide 100% support (1) for the JavaScript library MochiKit (version 1.4.1)!

The library’s own tests are integrated in HtmlUnit’s build and they now all (2) pass, no matter if we simulate Firefox 2, Firefox 3, Internet Explorer 6 or Internet Explorer 7. This time, it was not so complicated to reach 100% support: fix a bug in Rhino, implement a dummy support for the filters property on HTML elements when simulating IE, handle detached nodes for offsetParent, and fix a few things in computing CSS properties.

I believe that we’re on the right way and that we’ll soon be able to announce full support for other well known libraries.

(1) I suppose here that the library’s own tests are representative for the library usage.
(2) In fact we run only the tests files that pass in a “real” browser and therefore have to ignore 3 files.

Here are the slides of my presentation (in German) “Grails Plug-ins verwenden und selbst entwickeln” last week at W-JAX 08 in Munich.

The HtmlUnit project is pleased to announce the release of HtmlUnit 2.3. This release brings another round of improvements and bug fixes (the release process has taken an unusual long time due to problems caused by SourceForge datacenter migration).

Here is an extract of the complete change log:
- better generics support to avoid casting
- improved JS support, particularly full support for GWT 1.5
- Firefox 3 now in the list of the simulated browsers
- a CookieManager
- …

The generics improvements may require some simple code changes if you are using Sun Java 5 compiler due to a bug which has been fixed in Sun Java 6 compiler but not been back ported.

Download: http://sourceforge.net/project/showfiles.php?group_id=47038

Enjoy!