A few weeks ago I was asked by my friend and ex-colleague Steve Carpenter to present at the Flash Midlands user group. I couldn't resist the opportunity to spread the word about acceptance testing for Flex/Flash that we've written about here before (Flex acceptance testing demo, Running Selenium Flex tests in a Hudson job and Flex acceptance testing and continuous integration).
Apart from me managing to arrive late, it went well. The idea of acceptance testing was generally a familiar concept to people there, but the ability to do it in Flex and do it with nice refactorable tests, not recordings was quite a surprise to most people I think.
This is perhaps a point that could do with being made again:
Acceptance tests need to be written in such a way that they can be refactored along with the rest of your code
Acceptance tests that need to be re-written or re-recorded when your UI changes are more of a burden than a help. The way we get around this is to make sure that just as with your application code, our acceptance tests have layers of abstraction to separate the definition of the business requirements from the UI specific code that drives that actual pages.
A great way of doing this is to write a "Domain Specific Language" for your acceptance tests. This is a post for another day though.
Here is a quick recap of the tools I mentioned in my presentation:
Selenium - Tool to automate driving a web browser
Hudson - Continuous integration server
Selenium Flex API - Java to Flash bridge
We started using some of these tools around 2 years ago. The Flash Selenium and Selenium Flex API in particular have come on a great deal since we started using them.
The best place to go for a demo of our setup is Julia's article I mentioned earlier: Flex acceptance testing demo.