Creating Custom Runtime Loader

Creating Runtime Loader

Running Applications With Custom Runtime Loader

How to Exclude Objects of Runtime Loader From Object Hierarchy?

To create a custom runtime loader for Flash and Flex applications, you can use a template provided by Flex SDK. This template resides in the <Flex SDK>\templates\automation-runtimeloading-files folder and includes the following files:

• runtimeloading.mxml - Contains the source code of a wrapper Flex application. Note that the compiled Flex movie file (runtimeloading.swf) is not included in the SDK, therefore, you need to compile the application yourself by using the runtimeloading.mxml source code file.

• RunTimeLoading.html - A sample HTML page that is used as a wrapper for the runtimeloading.swf Flex application.

• build.bat - A helper batch file for compiling the runtimeloading.swf application with test automation libraries included.

To create a runtime loader for your Flash or Flex applications to be tested with TestComplete, do the following:

1. Compile the runtimeloading.swf Flex application from the runtimeloading.mxml source code file. When compiling, you need to include the TestComplete FlexClient helper library in the application to be compiled. The TestComplete package includes different versions of this library intended for different versions of Flex SDK used for compiling the application. All of them reside in the <TestComplete>\Open Apps\Flex folder:

   • FlexClient.swc - the automated testing library for Flex SDK v. 3.3 and 3.4.
   • FlexClient35.swc - the automated testing library for Flex SDK v. 3.5 - 3.6.
   • FlexClient4.swc - the automated testing library for Flex SDK v. 4.0 - 4.6, 4.9 - 4.14.

   When compiling the runtime loader, you must specify some compiler options:

   • To include the FlexClient library in the application, use the -include-libraries compiler option and specify the fully-qualified name of the needed version of the library in this option.

   • If you want to test SWF files of Flash and Flex applications compiled with network access enabled, then set the -use-network compiler option to true. Otherwise, if you want to test local applications using only local file system resources, without network access, then set this option to false.

     You must use the same value of the -use-network option when compiling the runtime loader’s SWF module and SWF files of the applications to be tested. Otherwise, the loader cannot load applications compiled with the -use-network option’s value that differs from the value used when compiling the loader. If you want to test both applications with network access enabled and applications that use only local file system resources, you can compile two versions of the runtime loader by using different values of the -use-network option.

   You can find detailed instructions on how to compile Flex applications with the FlexClient library in the Testing Flash and Flex Applications with the FlexClient Library section.

   Note that you can also use the build.bat batch file from Flex SDK to compile the runtimeloading.swf Flex application. However, you must modify this batch file by adding the fully-qualified name of the FlexClient library to the list of libraries to be included in the application. This list is specified in the OPTS variable in this batch file. By default, the list of libraries already contains a few names of test automation libraries that are not actually required for TestComplete and that increase the size of the compiled Flex application. So, you should remove the default library names from the list specified in the OPTS variable. Also, you should add the -use-network=false compiler option to the command line in the batch file if you want to test local applications, without network access. Otherwise, to test Flash and Flex applications using network resources, specify -use-network=true.

   The resulting runtimeloading.swf Flex application compiled with the FlexClient library is ready to load SWF movies of Flash and Flex and to make these applications testable at run time.

   Note:

   Make sure that the application under test was compiled without the TestComplete FlexClient library, since the loader already contains that library and applies its functionality to the loaded SWF file of the application under test. Otherwise, errors may occur.

2. Deploy the compiled runtime loader to your web server. Put the loader (runtimeloading.swf) and its wrapper web page (RunTimeLoading.html) into the same folder on the server. Also, you must copy the application to be tested (its SWF file) on the same server (for instance, you can put the application’s SWF file to the same folder where the runtime loader resides). If your runtime loader and the application to be tested are located on different web servers, the loader cannot load such an application for testing.

   If you want to test a local application that does not use network resources, you can copy the loader to the folder on a local hard drive where the tested application (its SWF file) resides, without deploying the runtime loader to a web server.

3. If you want to run the runtime loader and the tested application from a local file system, you need to add the tested application’s folder to the list of Flash Player's trusted locations. For detailed information on how you can do that, see the Setting Security Permissions topic.

Note that the created runtimeloading.swf application and the RunTimeLoading.html wrapper page are templates for creating runtime loaders for Flash and Flex applications to be tested. They just provide the ability to load applications at run time and to make them testable. You can create a custom loader and a wrapper web page for it by using these templates from Flex SDK and by extending them with the functionality you need.

To run your Flash or Flex application and make the application Open to TestComplete in order to perform testing, you need to load the RunTimeLoading.html web page in a web browser and pass the URL of the tested application’s SWF movie via the automationswfurl query string parameter. Depending on where your runtime loader and the tested application reside, you must use one of the following URL formats to open the web page of the loader:

• If the runtime loader and the tested application reside on a web server, you must enter a URL like the one below in the Address bar of your web browser:

  http://www.mycompany.com/RunTimeLoading.html?automationswfurl=MyApp.swf

• If the runtime loader and the tested application reside on a local hard drive, use the following format of the URL to run the tested application from the loader:

  file:///C:/MyFlexRuntimeLoader/RunTimeLoading.html?automationswfurl=MyApp.swf

When you open the page in a web browser by using the URL with the automationswfurl query string parameter, the specified SWF movie containing the implementation of the application to be tested is loaded by the runtime loader that is embedded into this web page. TestComplete treats the loaded application as a Flex Open Application (regardless of whether the loaded application is a Flash or Flex application). That is, TestComplete can access internal objects of the application and their public methods and properties via the wrapper application (the runtime loader). So, you can test your application as if it was compiled with the FlexClient library.

We would like to note that program objects of a runtime loader Flex application that serves as a wrapper for a Flash or Flex application become ancestors of the loaded application’s program objects in the application object hierarchy (you can see it in the Object Browser panel, for instance). In case of the simplest runtime loader (like the runtime loader template from Flex SDK) that just contains a SWFLoader control for loading SWF files, two extra objects (mx:Application, which is the main object of a Flex application, and mx:SWFLoader that loads SWF files at run time) are added to the object hierarchy as ancestors of the loaded Flash or Flex application objects.

The above-mentioned objects of the runtime loader are not important for testing applications that are run by the loader. These objects make the object hierarchy more complex, and fully-qualified names of test objects of the loaded application become longer, which makes keyword tests and scripts less readable. Furthermore, if you previously tested your Flash or Flex application exposed by the debug version of Flash Player or compiled with the TestComplete FlexClient helper library, your existing tests will work incorrectly if you run the application under test by using a runtime loader because names of application objects changed.

However, the Runtime Loader application shipped with TestComplete, makes its mx:Application and mx:SWFLoader objects “invisible” to TestComplete. That is, when you load your application within Runtime Loader, the object hierarchy displayed in the Object Browser panel does not contain these objects and the tested application is treated as if it was directly embedded into the wrapper web page, without using an intermediate runtime loader Flex application.

Note that you can also “hide” objects of your custom runtime loader so that these objects become ignored by TestComplete. To exclude the main object of your runtime loader Flex application and its child SWFLoader Flex control from the object hierarchy, you need to change the source code stored in your runtime loader’s .mxml file. You can do this in the following manner:

1. Specify the “tcRuntimeLoader” string as the name of the mx:Application object (the main object of the Flex application) in its name property. For instance:

   XML

   XML

   <?xml version="1.0" encoding="utf-8"?>
   <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" name="tcRuntimeLoader">
   
       ...
   
   </mx:Application>

2. Specify the “testLoader” string as the name of the mx:SWFLoader object (the SWFLoader Flex control that loads SWF modules of applications to be tested) in its name property. For instance:

   XML

   XML

   <mx:SWFLoader name="testLoader" id="myLoader" width="100%" height="100%" preinitialize="myLoader.loaderContext = new LoaderContext(false, ApplicationDomain.currentDomain)">
   
       ...
   
   </mx:SWFLoader>

After changing the source code as described above and recompiling your custom runtime loader, its mx:Application and mx:SWFLoader objects become ignored by TestComplete and are excluded from the object hierarchy. That is, you can run your Flash or Flex application within this loader and test it in a way as if the is running within its own wrapper web page.

Also, if your custom runtime loader’s main object, mx:Application, contains other child program objects, in addition to the SWFLoader control, these objects are not completely excluded from the object hierarchy after excluding the mx:Application object. They are moved within the object hierarchy to the same level as the level of the main object of the loaded Flash or Flex application (that is, these objects become siblings of the main application object).