WebTest Plugin 1.1.4.2 Released

A new minor release of the Grails WebTest plugin to allow the plugin to download the latest WebTest snapshot (which uses HtmlUnit 2.5 which fixes issues with testing JQuery 1.3.2).

It will download the latest snapshot by default when installed. If you would prefer the latest stable release (3.0) you can answer no when prompted.

Testing a JQuery-UI Drag and Drop using WebTest

Just a quick post regarding using WebTest with JQuery-UI Draggable and Droppable.
The way that WebTest performs a drag and drop is as follows:

from.mouseDown()
to.mouseOver()
to.mouseUp()

Note that there is no intermediate move events between mouse down on the thing you're dragging and mousing over the target element.
What this means is that you need to configure your Draggable to start dragging on mousedown without delay. You can do this by setting the distance and delay options to zero (delay is zero by default):

$('.block').draggable({distance:0});

WebTest will now be able to click and drag it correctly. Unfortunately due to HtmlUnits 'renderless' behaviour you cannot specify exactly where you want to drop it so if you require precise targeting to properly test your application you're out of luck.

Grails WebTest Plugin 1.1.4 Released

Another WebTest plugin release, this time with some new functionality!

Soenke Sothmann has contributed a nice patch to allow you to run custom suites of tests:

run-webtest -suite=MyTestSuite

Note that under windows you will need to quote the -suite argument due to an issue with Gant's argument parsing e.g. "-suite=MyTestSuite"

import grails.util.WebTest

class MyTestSuite extends WebTest {

    static void main(args) {
        new MyTestSuite().runTests(args)
    }

    void suite() {
        new SomeTest1(ant:ant).suite()
        new SomeTest2(ant:ant).suite()
        // You could also load up certain tests based on naming conventions or annotations
    }
}

In addition to this patch, there were some bug fixes relating to running webtests under Hudson and also around setting a custom port when starting up the server.

Grails WebTest Plugin 0.6 alpha

I've been working on committing some improvements to the Grails WebTest Plugin. You can download the alpha version here (I haven't yet released it to the plugin repository). I'd appreciate feedback from users with existing applications with non-trivial webtests regarding any regressions or upgrade issues they have. If all looks ok I will update the official repository version shortly.

Release Notes

• setUp/tearDown at the method and class level

  • classSetUp() and classTearDown() are run as individual test cases. SetUp() and tearDown() are run as the first and last steps of each test case.

• New superclass AutoWebTest

  • This new superclass will automatically run all methods starting with test. This saves you having to manually maintain the suite method unless you really want to for test order reasons.

  • AutoWebTest will also generate the test case name from the class and method name removing the need for repetitive webtest('blah'){...} code. The generated test name also makes it much easir to find the failing test from the generate reports.

  • MethodMissing code has been added so you can refactor a group of steps without having to wrap them in and ant.group closure.

  • You can now call config() as the first step in your test method to set WebTest options like host, port and ajax support

• -nostart option allows you to runthe tests against a server that is already running. It should come after run-webtest on the command line

• System parameters now passed through to WebTest. They need to be placed directly after grails on the command line e.g. grails -Dwt.headless=true run-webtest

  • -Dwt.headless=true to hide Swing monitor and stop browser launching

  • -Dserver.port=XXXX to get the tests to run against a server on a non-default port

• The plugin has been updated with the latest WebTest release which includes an update of HtmlUnit to version 2.3

• Application lib folder now on WebTest classpath. This avoids the need to duplicate/move libraries into webtest/home/lib

• Custom steps

  • You can now extend com.canoo.webtest.steps.Step by placing groovy classes in webtest/tests/step. They will be automatically loaded at runtime and allow for easy testing of complicated scenarios such as JSON interfaces and email integration

    • The last project I worked on used these custom steps to start, check then stop an embedded Wiser SMTP server for testing email functionality.

Upgrade Instructions

delete plugins/webtest-0.x

svn delete webtest/home, commit.

This avoids svn issues as the install script deletes the folder and extracts the latest build over the top, removing the .svn directories

grails install-plugin grails-webtest-0.6.zip

You need to copy the zip file into the root folder of your project and run the command there.

How to WebTest a site using an invalid SSL certificate

UPDATE: there is a option you can pass to the config step which should achieve the same thing: useInsecureSSL

A very short post regarding an issue I recently came across while testing an application I'm working on.

My application needs to interface with and existing PHP application that uses SSL. To acceptance test this functionality I am writing a WebTest that drives both applications to assert information is flowing correctly between them.

Unfortunately the test instance of the PHP application I have been given to use has a self-signed SSL certificate which causes WebTest to fail with a SSLHandshakeException.

To ignore the self signed certificate, add the following line to your test:

groovy('step.context.currentWebClientContext.webClient.useInsecureSSL = true')

Functional Test Driven Development with Grails and WebTest

EDIT: Most of this functionality is now available in 0.6 Alpha: This is not a new idea by any stretch of the imagination, however, I thought I'd post about how I've been doing it recently. The Grails WebTest plugin comes with a script which will start your application, run all your test, and shut down the application. This is great for checking your code before checking in or for running on your continuous integration server. However, if you would like to use a WebTest to drive out some functionality it is far too slow. To get around this I have been using a custom script and parent class for my WebTests. The script is basically a copy of RunWebtest.groovy supplied by plugin with the start/stop application code removed. It also has a small section of code to parse a class patttern and method pattern as arguments. It needs to be placed in the plugins/webtest-0.5/scripts directory of your application so that it can access the required WebTest configuration and resources. This allows for a command such as: grails run-webtest-only MyDomain edit which will run all test methods containing the word edit but only those methods found in classes with a name containing the word MyDomain. In order for this to work, you also need to modify call-webtest.xml, found in the plugins/webtest-0.5/scripts directory. Add clonevm="true" to the java tag at line 10. This is required so that the system properties set in RunWebtestOnly.groovy are passed through the java process that actually runs the tests. This allows you to pick out one or two key tests that you are working on and run them quickly and repeatedly without restarting the application. It also has a nice side effect of forcing you to write robust, repeatable tests as you will be running the test multiple times against the same database without refreshing the data. The second part of the solution is the custom parent class for the WebTests. By default, the WebTest plugin requires you to add a suite method to your WebTest to specify the order in which to run the test cases contained within it. This is very useful if there are dependencies between the cases and testA must run before testB for example. To me, this is a bit of a smell that your tests are too fragile. If testA must run before testB in order to set up some state, refactor the code that creates that state into a method and re-use it in testB with unique values so that you can run testB regardless of database state. Of course there are always exceptions, especially when it comes to keeping test execution time to a minimum, and in reality it may be better to set up common data once and re-use it in several tests. My opinion above is given with a "in an ideal world" disclaimer. Apologies, I'm getting side tracked! What my custom parent class does is model JUnit in that it automatically builds a suite from all methods beginning in 'test'. It also applies the class and method filters you gave to the run-webtest-only script which are passed through from Gant via system properties. Now with the help of the WebTestRecorder firefox plugin I can start to drive out a new page, menu item or behaviour. I find this method very useful in forcing a methodical, logical approach to developing new code and also makes it very easy to 'do the simplest thing' as you drive all code changes from the front end from the users point of view. As usual, there are always exceptions, and you should always refactor and add any additional integration or unit tests required to cover exception handling or complicated logic that you cannot drive out from a WebTest. My internal dialog normally goes something like this: "Right, so I need to add a new field to X. First, I need to record browsing to the list screen and creating a test X" click, click, click, cut and paste "Ok, next I want to be able to enter a value for field Y when creating an X." setInputField(name:'Y',value:'someValueForY') clickButton('Save') "This should now fail..." run-webtest-only XTests editY "Excellent, I can now go and modify the GSP to add the input field" and so on and so on... Make sure you you only do enough at each stage to make the test pass, in the above example, I could go off and add the field to the domain class and update the controller if necessary, however all the test is making me do so far is add an input field to the GSP. Once the test is checking that the value of Y is persisted and displayed on the show or list screen, then I can go and make those changes. It can be hard to stay disciplined but hopefully you have access to a pair and can keep each other honest. I openly admit to cutting corners when working on my own. It's not my fault, Grails makes my actual coding so fast, the tests just slow me down!! ;)