Saturday, 10 October 2009

Building & Deploying an Automated Flex Application

There are a couple of ways to building a QTP enabled application. The first approach is to directly compile your application with the automation SWCs. The second approach is to create an application with a SWFLoader that has been compiled with the automation SWCs and load in your main application. The pros and cons of the two approaches are discussed further below.

Building a QTP enabled Flex application is simple (details here), but the issues around it require some consideration. If you simply compile your application with the automation SWCs your production code will be automation enabled. This introduces a security risk by allow users (other than your test team) to use the application with QTP. There is also a performance cost because SWFs are larger (due to the addition of extra automation classes), which will increase the initial download time. A runtime memory and performance overhead is also observed due to the attachment of a delegate object to every instance of a visual component and the registering of these at application startup. More on delegates coming in a later post.

Regression testing should always be performed on the same build that will be used in production, this leaves the automated tester with a problem. Do you create two builds, an automated and non-automated one, or do you allow automation enabled applications to be used as production systems. I would always push for the former, although you may be best to let the teams concerned with security, performance and testing decide. If you do opt for building two versions of the application this will double your build time, not insignificant on most enterprise projects.

The alternative is to create a QTP wrapper application. This application will load you main application and enable the automated testing of it. If you have a basic application then you can simply use the example given on the Adobe LiveDocs. If you need to use custom delegates then you will also need to compile these into the wrapper application. When doing this it is vital that you load the application into the same Application Domain as the wrapper. Failing to do this will most likely cause run time exceptions or unexpected behaviour. The clear advantage with this approach is that you only need to compile one additional application and this application is small and quick to build.

Using the wrapper approach has one other benefit, and this is that your wrapper and application can have separate release cycles, meaning that fixing a QTP related bug does not necessarily require a new build of the whole application. For example, if you need to change the logic in a custom delegate then you can simply modify that and recompile the wrapper. As your delegates will reference and hence cause classes form your main application to be compiled in to the wrapper, you must ensure that the versions of these classes in the main application and the wrapper are the same to prevent run-time conflicts. One final tip is that if your loaded application requires flash args then you can simply pass them in through the source URL:
<mx:SWFLoader
 source=”loadedApplication.swf?myFlashArg=foo&myOtherArg=bar”
 loaderContext=”myContextWithTheSameAppDomain”
 />
In general I prefer the wrapper approach as it overcomes some of the concerns that the first approach raises. However, if you have a simple application where you are not concerned about the performance overheads (which are not that high on a small application) then the first approach may be easier for you. Although the first approach allows a user to easily use your application with QTP, if they really wanted to, they could follow the second approach and write their own wrapper and use it anyway.

No comments:

Post a Comment