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:

At Black Pepper Software we primarily deal with Java on the server side and then various kinds of front ends, but it's usually browser based. With the release of an almost feature complete Adobe AIR runtime for Linux (to catch up with Windows and OS X), I felt it was time to experiment a bit more with what a modern desktop app was like.

Trying out AIR was a natural step for me as I've been spending a lot of time doing Flex recently, but I've never done desktop development before. This is partly because in this day and age it is so easy to keep your web app up to date without the deployment costs and versioning problems you get with desktop software. What happens when you have a desktop app that is connecting to some web services and you want to change those services? You've got to update your desktop app and make sure that your users get that update, otherwise things will break.

AIR doesn't come with an update framework built in, but there is one in Adobe Labs at the moment which works a treat called the Adobe AIR Update Framework. I will point out up front though that the Update Framework is NOT open source, in fact, no source is provided at all except for the samples of how to use it.

As you may gather from other entries in this blog, we've been working on a customer project which uses Flex for the client and Java for the server, with SOAP over HTTP in between. It worked well for us as a combination, because it minimised the number of new things to be learned - helpful when you're dealing with, er, aggressive delivery timescale aspirations. I've been having a few doubts about its long-term viability, though. SOAP's pretty verbose, and I'm not sure how quick the marshalling to/from XML is in ActionScript. Anyway, I was lucky enough to have a bit of spare time to investigate BlazeDS as an alternative, and thought I'd share some of the experience.

I downloaded BlazeDS and the sample applications to use as a guide in converting my existing web application. I'm not going to go into all the details here since that's not really the focus of this article - the Adobe BlazeDS Developer's Guide is well worth reading. Our server side code is a Spring application, so some extra work was required to make Blaze and Spring work together. Fortunately, Christophe Conraets has written an excellent article on the subject, along with some very handy sample code, which I have made use of.

Our server-side code is a Spring application, but there are a few minor peculiarities in the way it uses Spring 2 Security. The server is completely stateless, so the Flex client has to authenticate each request. For the SOAP version, we pass an authentication token in a custom HTTP header (Flex prevents you from accessing certain HTTP headers, the Authorization header included). In the BlazeDS version, I had to find another way of authenticating, since I couldn't see a way of getting access to the HTTP request that it uses to send the request to the server, so no way of adding my custom header.

Google Analytics provides an easy to use interface that tells you which pages on your website are being accessed, how often they are accessed, and lots of other useful information about how your website is used. The problem for me on a recent project was to collect usage statistics for a Flex application. To use Google analytics you simply include a small javascript element in each page that's served. When the browser executes the javascript a small message is sent to google recording the page URL that was accessed and some other details about the client.

The first problem with a Flex application is that it's really just a single big(ish) download of the swf (Flash) file, so all that will get recorded is the fact that someone accessed your application. If the Flex application has several different views within a view stack none of the navigation between those views will be recorded. In addition, if the Flex application is using web services to communicate to a backend server, these requests wont be recorded either. Here's how I got my Flex application to record statistics of the navigation within the application and the web service calls made to a backend server.

When you register your website with Google analytics you're given a javascript element to include in your pages. Start by adding this javascript to your html file that loads the Flex application. It should look something like this:

When you set up a new Flex Project in Eclipse (either FlexBuilder 3 or the plugin), the new project wizard asks you if you want to use a remote object access service, such as LiveCycle Data Services (LCDS). You can use the same option to access BlazeDS services running in a J2EE server. It requires that you have your BlazeDS server running, because the next step asks you to enter the root folder and root URL of your server.

If you want to be able to compile your Flex project without the server running, you can get around this.

If you look at the documentation for the mxmlc compiler, you'll see that the context root and the location of the services definition file, services-config.xml (which are the two things the wizard is really after), can be specified as command line arguments. SilentWalker talks about using this with the Flex Ant tasks in his blog.

Giving users the option to have your application remember their login details is a simple and really useful feature for any desktop app to offer. Web browsers have had this feature for a long time now and you can even store your usernames for your Flex web app in a SharedObject...but when storing passwords, you have to be quite careful with how you store the data.

Thankfully EncryptedLocalStore comes to the rescue in AIR, but it's not available in the browser.

My test app for this is a simple two screen Cairngorm AIR app. I'll skip over some of the boilerplate of the app and just get down to the nitty gritty.

As I look deeper into Flex testing, I keep coming across little problems that are so easy to deal with in Java, but just aren't as simple as you might think in Flex.

One of these problems is testing chunks of code that call off to live services. There are two bits of technology that make this easy in Java and that's mock objects and Inversion of Control (IoC) for dependency injection. Flex doesn't natively do either of these.

Dependency injection is available via a couple of IoC frameworks that are available for Flex. Mock object frameworks don't seem to exist yet for ActionScript, which is a shame. So, what do you do?

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?

This is part 2 of an article about testing Flex and integrating Flex into a continuous integration environment so it's worth reading part 1 first.

FlexUnit in Ant

Once you've written your unit tests for your Flex project, how are you going to run them? Sure, you can just fire up the test runner that I wrote about before, but you've got to remember to run it and actually look at the green/red bar to know if things are going wrong. Ideally you'd get your unit tests to run as part of your build so that you get the advantages of continuous integration.

With this in mind, I took a look at Peter Martin's FlexAntTask which allows you to run your FlexUnit tests from within an Ant build.

I wrote recently about a project where we had to put a Flex front end on top of a set of SOAP web services. Most server side programmers are hopefully now pretty comfortable with unit testing their server side code using something like JUnit. However, testing Flex applications isn't quite as mature yet and with a lot of Flex developers coming from backgrounds where unit testing isn't so ingrained, there isn't that much written about it.

There are three major different aspects of testing a Flex app that you might want to do.

1. Unit testing: Testing individual bits of ActionScript such as individual classes or methods
2. Integration testing: Testing how your app is actually wired together such as do the right events trigger the right commands
3. Acceptance testing: Testing the whole app, including how it behaves in a realistic deployment environment

These are ordered in terms of simplicity. Unit testing as hopefully I will show is pretty simple, but things get a lot trickier when it comes to Integration and Acceptance testing, so I'll leave those for another article...hopefully by someone else :)

Unit testing thankfully is also a good place to start because the more unit testing you do, the less integration and acceptance tests you are likely to have to write.