The demand for testing Flash/Flex applications has become much more significant during the last few years, indicative of widening use of this technology. Along with this demand came the need for automating tests upon these applications. However, this need raises a few questions and problems, some of which will be discussed in the following article.
The demand for testing Flash/Flex applications has become much more significant during the last few years. This indicates widening usage of this technology, which in turn illustrates a need for automated testing of these applications. However, this need raises a few questions and problems, some of which will be discussed in the following article.
Specifically, the first question that must be answered about automating a Flash/Flex application is: which is the right automation technique? There are two distinct ways to go:
Native mouse & keyboard integration – good for situations where there is minimal Flash interaction required.
API-level integration – good for situations where there is a lot of Flash interaction required.
Native mouse & keyboard integration – This is where a mouse movement, mouse click, or keyboard action is simulated at the operating system level. It reproduces the most realistic user simulation by recording GUI-based actions, getting us very close to “real life” use of our application. However, using this method has some problems. For example, testing a Flash application requires that the application and the testing environment be prepared in a special way. There are different ways to make your Flash application testable, depending on the testing tool used and development environment. Some tools such as TestComplete, Rational Robot, and QTP require that a dedicated library (usually supplied by the tool’s vendor) be embedded in the Flash application during compilation or at run time. Specifics of this process can typically be found within the documentation of these tools.
Capturing the objects in a Flex/Flash application is problematic on its own. To solve this, there are two main approaches:
- Capture the display from the device and employ image recognition to locate desired elements on the screen, automating the application in a black-box manner. EggPlant is a good example of a tool that utilizes this approach. It is also how SilkPerformer operates in a Citrix environment.
- Parse the objects being used into properties and use those properties to locate the object. This is the same approach that is used in QTP’s object repositories. Typical Flash object properties such as state, name, and text get used both to locate objects and verify that certain actions have taken place. Rational Robot is a good example of this approach; it uses 11 different Verification points to verify that a certain action has taken place, or verify the state of an object. This approach is perfect for those who want to simulate relatively simple GUI interactions, such as clicking on a movie’s “play” button or interacting with a confirmation dialog, as on a more complicated application this approach tends to fail.
API-level integration – For applications that have much more complex Flash/Flex user interfaces or applications that are 100% Flash-based, it is hard to use GUI capturing as presented since it can be brittle and difficult to confirm that the desired functionality worked. For this, one can use the API level integration. To do this type of automation one must be able to recompile/modify the underlying Flash object(s).
How you proceed from here depends on whether you are using Flash or Flex, as Flex exposes some automation APIs that will, otherwise, have to be reproduced if you are using pure Flash. To do this one can:
- Use the External Interface package supplied by Adobe directly – most reliable, but this might require the most programming
- Use open source libraries to make External Interface callbacks easier to use. It is basically a component which adds Flash communication capabilities to an automation framework, such as FlashSelenium (For Selenium users).