I've written in an earlier blog entry about writing acceptance tests in Java for a Flex front ended web app, using Selenium RC. Here I'll describe how we added those tests to our continuous integration build, using a Hudson job as part of our build-and-deploy pipeline.

Our web app comprises two components, a Java server-side component and a Flex client-side component. The Java component is built by a Hudson job as a war file. The Flex component is built by another Hudson job as a zip file. These two Hudson jobs are independent, fairly standard projects built by Ant, each with its own set of unit tests. To run acceptance tests, we need both components to be deployed into the target environment. We created a third Hudson job which aims to deploy the latest artifacts from the Java and Flex jobs, start up Tomcat and Selenium, run the acceptance test suite, and shut down Tomcat and Selenium. This Hudson job depends on the other two jobs and its build is activated when either of those two completes.

As we are already using Ant to control the two component builds, and our acceptance tests are written in Java, we decided to use the Ant build for the Java component as the home for the acceptance test build. Here's the target to run the acceptance tests in the Hudson CI environment:

JAOO 2008 was brilliant.
My top three talks, as requested by the conference feedback form:

• Failure comes in flavors by Michael T. Nygard: because the lessons in how to prevent and recover from failure were valuable and the failure stories were funny.
• Software Architects and Testing by Peter Zimmerer: because the message of making testing your responsibility, as software architect, and promoting testing practices to your team, was right.
• The Lively Kernel by Dan Ingalls: because of the mind-boggling demo of rotating stars, clocks and worlds created on a base of JavaScript and SVG.

My other feedback was on water.

“It is about bottled water. This comes at a big environmental cost. I suggest that instead of offering free bottles of water every day, each conferee gets one empty bottle which they fill as required from water fountains or water coolers placed around the conference area.

The problem I had is how to automate acceptance or functional testing of a web application with a Flex front end. I wanted to solve this problem because functional testing increases confidence that the software meets customers' requirements. Automating the tests - coding tests and running them as part of the build - pays dividends over and over, as agile developers well know. We're able to check that user stories are implemented and catch bugs early in the lifecycle.

Kieran's blog entry unit testing Flex tells how he solved the problem of writing and automating unit tests for Flex front-ends. He found there was little available material on unit testing for Flex - and I found even less on acceptance testing for Flex. However, we had done automated acceptance testing for non-Flex web apps.

Selenium is a popular tool in the open source community for automating functional tests for web applications. It allows developers to write tests that drive your web application via the browser. You can write tests in various languages, including Java and JavaScript, and in the test you can manipulate web page components using XPath or JavaScript. So for example I can write a test to enter text into an input element of an HTML form, click the submit button, and verify data on the response page. But how can I do the same sort of thing for a Flex front-end?

Recently we had a problem in satisfying a requirement to secure the HTTP requests and responses for a web application.

The application consists of a Flex front end and a Java web application accessed as Web Services by the front end. The Flex app is hosted by Apache and the Java web app by Tomcat. The Web Services are created by XFire annotations on the Java interfaces.

Apache is hosted on a physical server in a DMZ. Tomcat is hosted on a second server behind a firewall which blocks external requests.

I've just configured Apache for SSL and it took longer than I thought it should. I didn't find any straightforward instructions on the web so here's what I eventually did - after a deal of experimentation. These worked for me running apache 2.2.8 under Linux - Hardy Heron.

I generated a self-certified certificate:

openssl req -new -x509 -nodes -out /etc/apache2/server.crt -keyout /etc/apache2/server.key