Polymorphic rants

Acceptance Testing is a fundamental practice: it gives you confidence that your application behaves as expected from the end customer point of view. In the Flex world there are some projects that are currently emerging in the Acceptance Testing space, each one with specific advantages and weak points. Let's have a look to some of these. FlexMonkey FlexMonkey Open source but based on closed source API (the Automation API are released only with FlexBuilder and not with the open source Flex SDK), it's based on the record-playback approach and as far I  have seen is not easily integrable with a Continuous Integration server. Flash-Selenium Flash-Selenium is open source, and it works as an extension of SeleniumRC; the tests can be written in Java, .Net, Ruby or Phyton and the integration with a Continuous Integration server is therefore quite out of the box. SeleniumFLex API SeleniumFlex is another open source project. it's an extension of SeleniumIDE, test should be written in Selenese. FunFX FunFX is based on the automation API (therefore you can use it only if you're owner of FlexBuilder), the fixtures are  written in Ruby. At the moment there isn't a  de-facto solution: the community is quite dynamic and all these different tools are trying to find their space. Which one is  my favourite ? It's really hard to say, I think that the context matters a lot. I  don't like the solutions that require the Automation API simply because this tights you to a vendor just for testing; it's also true that the pure open source solutions requires some extra-hack (like exposing methods through  ExternalInterface) that are less than ideal. Looking at the two pure open source tools I like Flash-Selenium for its out of the box integration with Continuous Integration server, while I prefer Selenium-Flex approach for handling the necessary ExternalInterface configuration.

In a previous post I was discussing on my experience with Flex and one of the highlighted pain points is the extremely poor quality of the available tutorials. Let's have a look at the source code of the Flick tutorial: In a single page you have:

• the declaration of visual components (TileList)
• the declaration of non visual component (HTTPService)
• event handling (photoHandler)
• data binding (photoFeed)
• pure logic (requestPhotos)

If you decide to follow this development model you will obtain something that is extremely fragile to evolve or simply just to maintain. Let's start assigning the right responsibilities to the right objects. The first step is creating our own Application object and use it as root in the mxml file: Now the HttpService component is not exposed anymore (and ideally can also be injected) and the events handling in the right place. The second step is to extends the HttpService object to place the requestPhotos behaviour in the service. The result is below: At the end of this refactoring our mxml file looks like this: Now we are declaring only visual components, and its only role is defining what we want to see and how. This is the way of writing code. The other one is just rubbish.