An Architect's View

A few weeks ago, I blogged about a fix for running Selenium with ant on Snow Leopard and several people have asked me to blog about the basic setup for which that fix applies since it is of much broader interest to developers... Yes, good point! A bit of background first. I'm working on a large ColdBox project and one of the first things I did when I joined the project was to start creating some unit tests and integration tests. ColdBox has integration with MXUnit so you can fairly easily write unit tests for parts of your model and integration tests for your event handlers. Over time we've built a suite of over 100 MXUnit-based tests. If I had my way, we'd have a lot more by now but test-infecting your colleagues isn't always easy!Once we had enough of the system working, testing some of the complex flows through the application became pretty tedious and some sort of automation became necessary. We picked Selenium since it offers a plugin for Firefox that lets you record a click-thru session for your application and play it back. Selenium tests are saved as simple HTML documents with a table listing actions, targets and values in three columns. You turn this into a test by adding rows into the table that assert text is present (in the rendered page). You might end up with rows like this: The next step is to assemble these test scripts together in test suites. Again, these are simple HTML documents with tables. This time tho' the tables have a single column that contains a link to a test script in each row. The scripts and suites can be run in pretty much any web browser using the Selenium core/TestRunner.html test harness. The final step is to fully automate these suites by running them automatically as part of your ant build script. You have an ant build script, right? When you download Selenium, you get an IDE to install into Firefox (an XPI file) and a JAR file, which is what you need for use with ant. A good idea is to create an "init-selenium" target in your ant script that looks something like this: This assumes the property selenium.home is already set up to point to the folder where you installed Selenium. This ant target can be used as a dependency for other ant targets that actually run Selenium tests. It defines the <selenese> ant task (by pulling its definition out of the properties file in the Selenium JAR file). After this target has run, you can execute the following ant task: Again, this has a number of ant properties predefined just to make the script easier to customize. The browser property is normally going to be "firefox" but could be "safari" or any other browser supported by Selenium (such as "iexplore" if you must). The selenium.host property specifies the base URL of the web site that should be tested and the tests property specifies the root folder for your Selenium tests (I have lots of different types of tests in that directory, including the Selenium tests). I hope that gives you a taste of how to get automated testing going with Selenium. In addition to our 100+ MXUnit tests, we now have three suites of automated Selenium tests covering several areas of our application. Our ant build script resets the entire state of the server and database and runs our Scala test suite (I blogged about that a bit before), our MXUnit test suites and our Selenium test suites in anything between three and eight minutes depending on the speed of each developer's machine.