Monday, 19 October 2009

“Updating Duplicate Resources”?

What is Flex Builder doing when it tells you it is “Updating duplicate resources” at the end of building your application? During this step Flex Builder copies over various files other than the compiled SWFs to your output directory. These files include everything in your html-template folder and any non-embedded source files. Depending on where you build to, this can take a fair bit of time. For example, if you build to a directory on a non-local web server.

There are a few ways to minimise this and hence speed up your builds a little. The first is to unselect the “Copy non-embedded files to output folder” option on your projects’ compiler settings. This option causes any files under your source directory to be copied to the output directory if they have not been compiled into the SWF. You may however need this option if you keep files such as assets under your source folder that need to be loaded by your application from the build location.

The second thing you can do is to only keep required things in your html-template folder. By default this contains a Flash Player installer SWF and history files, in reality you probably only want to distribute these with you release builds and not copy them over every time you compile the application as a developer (hopefully you have Flash Player installed!). The problem may be even worse if you build modules, because each one of these may have an html-template directory. Sometimes it is convenient to keep other files in your html-template, such as assets, xml data files, etc. If the content of these has not changed since you last build then there is no need to copy these over again as it just adds time to your compilation. I would suggest just copying these over manually when they change or creating a simple script to do it for you. You could even link this script into Flex Builder as an External Tool so that you can run it from Flex Builder.

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.

Wednesday, 30 September 2009

Flex Manifest Files (with Flex ant)

All of the Flex framework components are mapped to a single namespace, this means that you are only required to use one import in MXML to use any framework component (xmlns:mx="http://www.adobe.com/2006/mxml"). The main advantage of this is a short list of imports, but it also means that the underlying package structure could change without needing to recompile your MXML classes.  Note that Actionscript classes always require the full package name when imported.  The following snippet provides an example of how the single namespace will appear even though the three components are in different packages:
<mx:Application
   xmlns:mx="http://www.adobe.com/2006/mxml"
   xmlns:custom="http://custom.namespace"
   >
   <custom:MyComponent />
   <custom:MyContainer />
   <custom:MyAsset />
</mx:Application>
It is actually possible to do the same for your own libraries, by using a manifest file. A manifest file is specified when compiling your library, and it provides a mapping between a single namespace and a list of fully qualified class names.  Your library must be included as a SWC in Flex Builder in order for the single namespace to be picked up, it will not work if the library is included as a project.  Auto-complete will work in Flex Builder providing the library is included in this way.  Although a new namespace is specified, the old namespace can still be used, this makes introducing a single namespace backwards compatible.

There are two steps to compiling your library in this way, the first is creating a manifest file. This is a simple XML file like the one below, which specifies mappings between the fully qualified class name and the new tag for the class:
<?xml version="1.0" encoding="UTF-8" ?>
<componentPackages>
   <component id="MyComponent" class="com.benlondon.component.MyComponent"/>
   <component id="MyContainer" class="com.benlondon.container.MyContainer"/>
   <component id="MyAsset" class="com.benlondon.asset.MyAsset"/>
</componentPackages>
The second step is to specify the new namespace and manifest file to the compc compiler. In this example the compiler arguments would be:
-namespace http://custom.namespace manifest.xml
-include-namespaces http://custom.namespace
The Flex ant compc task requires configuration as follows:
<compc ...
  >
   <namespace uri="http://custom.namespace" manifest="manifest.xml" />
   <include-namespaces>http://custom.namespace</include-namespaces>
</compc>
Once you have built your library as specified above, users of your library are ready to start using a single namespace. Flex Builder seems to choose the namespace prefix (in my example "custom") as the first part of a URL chosen as a namespace.

Wednesday, 16 September 2009

Introduction to QTP with Flex

Over the last couple of years Flex has brought the Flash platform in to a new era of RIAs. Flex is now being used for a range of projects of all scales, from simple animated websites to complex systems providing real time data, which have never previously been seen in the browser. As larger applications are developed with Flex, the challenges of testing large systems which are traditionally only associated with desktop applications arise. Automated testing claims to provide cost, resource and time reduction to the testing teams of large projects. These are my thoughts and findings on the matter from the perspective of a Flex developer on a large Flex project.

QTP

Quick Test Pro (QTP) is an automated test tool used for testing all sorts of applications written in a plethora of languages, from html web pages to .NET applications. The product is produced by HP ( and formally Mercury ) and provides integration with the test and defect tracking tool Quality Centre. The Flex SDK is bundled with the add-ins required to build a QTP testable Flex application. Two steps are needed to automate a Flex application, the installation of the QTP Flex plugin and compilation of your Flex application with the QTP/Automation SWCs, both of which are provided with the Flex SDK. In theory, from this point on you should be able to record and run scripts for testing a Flex application with QTP. The test scripts are in VBScript and rely heavily on the concept of the QTP object repository.
QTP builds up it’s own view of the hierarchy of components in your application, known as the object repository. This is build at the time the scripts are recorded. The VBScripts then run against this object repository to locate objects in your Flex application and dispatch events on them to mimic user interaction with the controls. The QTP SWCs load in XML files which describe the components they can interact with, this includes the properties and functions of the components. A standard TEAFlex.xml file describes the standard Flex components and a TEAFlexCustom.xml file is used to describe your custom components.

How it All Works

QTP can only connect to applications running in Internet Explorer (watch out for this if you cannot get QTP to connect to your application) as it relies on using ActiveX to communicate with Flash Player. Flex attaches a delegate object to every component so that automated tools can communicate with the objects. A delegate will be automatically attached to every object. The use of delegates is a way of removing automation code from production code so that automation code is not build into non-automation builds of an application, hence keeping the SWC/SWF size down. These delegates add event listeners to your objects so that they can inform the automation tool of the action that was performed so that it can be recorded. The standard automation delegates are provided in automation.swc, but you are free to add your own for custom components or if you wish to deal with a situation that the standard implementations do not support.
When you replay an automation script it will find the object in question, by traversing the hierarchy of objects in your application (which it gets from its object repository). It will then recreate the event which was recorded and use the delegate to dispatch the event on the object to mimic the dispatching of the event as if the user had interacted with the component.

Pros

The advantages of automating the testing of large systems is quite clear. Testers can spend less time regression testing every time there is a release candidate ( or even on a nightly build basis) and can spend more time building up thorough test suites for new functionality. Regression testing is a tedious task and despite a developer saying “it’s a small change and won’t affect any other part of the application”, should always be carried out! The overhead of this on a large application can be very high, sometimes a matter of days, to a week. The knock on effect of this is making release cycles longer and increasing the time to apply urgent patches. The theory is that the effort put into writing manual test cases can instead be put into scripting automated test cases and from that point on, minimal effort is required to repeatedly run these tests. This does, of course, require testers with these skills, and programming scripts in VBScript is not necessarily a skill that most testers have.

Cons

In my experience, the cost of maintaining these scripts is high. QTP/Flex rely heavily on the layout of the application to locate objects and on their IDs if a specific automation name is not applied. The problem with this is that if a developer changes the ID of an object of moves it in the view hierarchy the scripts will break. Even changing the type of a container will cause a script which uses the child of that container to fail as it cannot locate the required child. On a reasonable stable code base this may not cause a huge problem but on a project at the peak of development these changes can break huge amounts of scripts. For example, changing the type of a container directly under the main application from a Canvas to a VBox will most likely cause every script to break. The only way around this is to ensure that scripts are written in a way to avoid this, for example using variables to hold high level components, so that their type/automationName only needs changing in one place, at the variable declaration. Note that the Object Repository will also need changing, but this is only a change in one place. These sort of changes will lead to false negatives, tests failing not because the application’s functionality has regressed but because the test script is no longer in line with the application.

The speed of execution of these scripts is not particularly fast, I would expect a standard length test including application startup to take between 20-60 seconds. Ideally the application should be reloaded between every test so that any side effects of the first test do not affect the next test. For a large test suite I have found that automated testing is not as quick as people would expect, but it is still quicker than a human performing the test, although somewhat less intelligent and more brittle.

Automated testing is good at testing certain types of tests, such as those involving data entry. Testing for regressions in the appearance of the application however cannot be performed, this still requires the watchful eye of a tester. An example test may be that once an online store order has been placed using a Flex UI, confirm the order has been correctly entered into a database and is now in another order fulfilment system. Once again, this is something that QTP is not going to be able to help you with, you need a tester to access these down-stream systems to check that everything has worked.

One particular feature that I have found to be missing from the Flex integration with QTP, is the ability to “sync” on objects. When interacting with most platforms QTP can wait until an object is available before trying to interact with it, for example when you are waiting for a popup to appear, this is know as “syncing” on an object. The lack of this with Flex means that you have to hard code waits of set time periods, which can obviously fail based on the indeterminate time that some operations may take. The alternative is to write a slightly more complex function that continuously checks for an object’s presence and only interacts with it when it is present. Both methods add bulk to your scripts and add complexity for testers writing the scripts who shouldn’t be too concerned with this problem.