Test Adobe Flash Flex Using AMF Protocols

Build A Test of an Adobe Flex/Flash Service
With Native AMF Protocols

This article shows how to build a test in PushToTest TestMaker using AMF Protocols to test Adobe Flex/Flash based applications.

Note: Find all of the code and data described in this article in /tutorials/FlexFlashAMFTests.

AMF is a network protocol that makes it easy for Flex and Flash components running in a browser to communicate with PHP, Java, and other back-end technologies. TestMaker provides a native AMF protocol handler.

AMF is the Action Message Format. AMF is a proprietary data format created by Macromedia (now Adobe) and used by different mediums: Flash Remoting, ByteArray, IExternalizable, NetConnection, NetStream, LocalConnection, Shared Objects and more. All of these mediums share the same core data types and ActionScript data types. Each medium uses its own exclusive envelope. Any AMF-related project should implement reading and writing core data types, relevant Actionscript types, as well as providing support for its envelope type. Click here for tutorials on open source AMF.

Tasks and Scenario

This tutorial uses an example Directory application that ships with TestMaker. The tutorial shows how to develop a data-driven functional test of the Directory application.

Install The Directory Application
Write A Unit Test For The Directory Application
Run The Test In A TestNode
Repurpose The Test As a Load Test
Repurpose The Test As a Business Service Monitor

Test Use Case

A software quality tester needs to rapidly build a test of an Directory application. The application keeps track of contact information for employees.

The test begins by adding a new person to the directory. The test then gets a list of people in the directory. The test asserts that the new person is in the directory. If the person is not in the directory the test throws an exception and TestMaker logs the test as a failure.

This tutorial should take you approximately 45 minutes to build and operate a test. The following sections show step-by-step instructions.

Implementation

This tutorial comes with pre-built tests that are found in the tutorials/FlexFlashAMFTests directory. See the following files for the implementation:

File or Directory	Description
Tutorial_Flex_AMF_ReadMe.html	This document
DirectoryUnitTest.py	Unit test of the directory application
AMF_Functional_TestScenario	Runs the DirectoryUnitTest as a functional test
AMF_Load_TestScenario	Runs the DirectoryUnitTest as a load and performance test
AMF_Monitor_TestScenario	Runs the DirectoryUnitTest as a business service monitor
data.csv	Comma separated value (CSV) file of data for the DirectoryUnitTest
images	A directory of illustrations for this document
openamf.war	The Directory Web application. Installed automatically by the TestMaker installer.

Task 1: Install the Directory Application

The TestMaker Installer offers to install "Example Services for Tutorials." The Installer puts the openamf.war file into the local TestNode application server (TestNode/webapps). If you did not choose this option when you installed TestMaker, copy the openamf.war file manually, then restart TestMaker. The Directory Application URL is http://localhost:8080/openamf/gateway.

Installer offers to install tutorial services

Task 2: Write A Unit Test For The Directory Application

The following Jython script accomplishes a unit test of the Directory application.

'''

A unit test of the Directory application. Demonstrates use of the Adobe
Flex/Flash


AMF protocol handler in PushToTest TestMaker.



For details see http://www.pushtotest.com



(c) 2009 PushToTest. All rights reserved.

'''



import sys

import re



from com.pushtotest.tool.protocolhandler.AMF import AMFProtocol


from com.pushtotest.tool import PTTStepListener



class AMFTest:

    def __init__(self):

        self.AMF = AMFProtocol();



    def setUp(self):

        pass




    def runTest(self,person):

        ''' 

        Add a new person to the
directory and check that the person is 

        actually in the directory.
Receive the person data from a 

        provided hashmap from a
TestMaker Data Production Library (DPL.) 

        '''




        PTTStepListener.startStep(
"setUp" );

        

       
self.AMF.setup("http://localhost:8080/openamf/gateway");

        self.AMF.setVerbose(1);



        PTTStepListener.endStep();

        


        PTTStepListener.startStep(
"addPerson" );



        data = [person];

       
self.AMF.invoke("org.openamf.examples.Directory.addPerson",data);



        PTTStepListener.endStep();

        

        PTTStepListener.startStep(
"getPeople" );


        

        name =
person.get("firstName");

        data[0] = name;

        result =
self.AMF.invoke("org.openamf.examples.Directory.getPeople",data);



        PTTStepListener.endStep();

        


        PTTStepListener.startStep(
"tearDown" );



        resultperson = result[0];

        print resultperson;



        self.AMF.teardown();



        PTTStepListener.endStep();




    def tearDown(self):

        pass



def getAMFTest():

    ''' Needed by TestMaker to instantiate this test
object '''

    return AMFTest()

The unit test follows the jUnit TestCase interface definition. It implements methods for setUp, runTest, and tearDown.

The runTest method instantiates an AMF protocol handler provided by TestMaker's TOOL protocol handler library. The test establishes the Directory application service endpoint. The test invokes the addPerson service. The test waits for a response and then invokes the getPeople service.

This unit test is decorated with two TestMaker provided features: Data Production Library provided data and Custom User Step Logging. The runTest method receives a Hashmap referred to as person. The Hashmap contains name/value pairs retrieved from a comma separate value (CSV) file. person contains firstname and lastname key values.

The PTTStepListener startStep and endStep methods define the start and end to each Step in the unit test. TestMaker logs the success/failure and time it takes to operate each Step. This is later used for root cause analysis and mitigation of functional and performance problems. For example, TestMaker displays the Step information in a results chart when it operates the test.

Task 3: Run The Unit Test In A TestNode

PushToTest provides an easy-to-use central console that sends the unit test to one or more TestNodes. The Jython ScriptRunner in theTestNode operates the test. The test makes requests to the application or service to be tested. The test in this tutorial makes requests using AMF protocols. The TestNode logs the time it takes for the application or service to respond and returns the transaction logs to the PushToTest console.

The PushToTest console identifies the operating parameters of a functional test, load and performance test, and business service monitor in a TestScenario document. Four TestScenario instructions tell TestMaker everything it needs to operate the unit test of the AMF Directory application. Find a TestScenario document already created for you in FlexFlashAMFTests/AMF_Functional_Test.scenario

In TestMaker use the File menu -> Open command. Choose FlexFlashAMFTests/AMF_Functional_Test.scenario
TestMaker opens a new controller panel for the TestScenario. The controller panel includes icons to run, pause, and stop the test.
Click the Edit icon in the controller panel to view the TestScenario document. This action opens the Editor.

The tabs in the Editor set controls for the TestScenario:

Use the General tab identify test name and details. Use the General tab to set the test type and parameters. For example, this test is a functional test that runs the use case once.

Use the UseCases tab to identify one or more unit tests for TestMaker to run.

The TestNodes tab tells TestMaker to send the Jython unit test to one or more TestNodes for operation.

Monitoring identifies the PTTMonitors for TestMaker to observe while operating this TestScenario. PTTMonitor observes CPU, Network, and Memory usage.

Options control timing, logging, proxy, and bundle settings. Bundles send supporting resources (JAR files, scripts, and libraries) to the TestNodes.

Notifications send email messages hourly, upon test start and stop, and when tests encounter errors.

TestMaker stores Jython resources on the TestNode in the ./resources directory for handy access from Jython modules.
In the General tab, change the Repeat value to 5. This is to repeat the Use Case for each of the 5 rows of data in the data.csv file.
Define the Use Case for this TestScenario using the Use Cases tab. Click the Use Cases tab.

Set the UseCase Name to AMF Test Case.

Choose Jython in the Test Type drop-down menu.

Set the Test Name to AMF Test.

Click the Resource, Browse button. Choose the DirectoryUnitTest.py file.

Set the Class to AMFTest.

Set the Method to runTest.

Set the Instance to mytest.
Data-enable this test by adding a Data Production Library (DPL.) The DPL reads rows of data from a comma-separated-value (CSV) file. A Data Production Library (DPL) reads the name of the person to be added to the directory from a comma separated value (CSV) file. The DPL in this use case reads the next row of data from the CSV data file and provides the data to the unit test.

Click AddDPL under the AMF Test step.

Click the Resource, Browse button. Choose the data.csv file.
Identify required Bundles to operate the unit test. For example, the Jython unit test uses the AMFProtocol class in the TestMaker Tool library:

from com.pushtotest.tool.protocolhandler.AMF import AMFProtocol

TestMaker includes the AMFProtocol class in the Tool Bundle. The AMFProtocol uses the BlazeDS libraries. Bundles are stored in TestNode/Bundles.

Add the BlazeDS and Tool Bundles in the Options menu.

Click the Options tab. Click the Add Bundle link.

Set the name to tool and version to 1.0.

Click the Add Bundle link a second time.

Set the second new Bundle to blazeds and the version to 3.0.

Click the Add Bundle link a third time.

Set the third new Bundle to jython and the version to 2.2.1.
Click the Run button in the controller panel and watch the results.

Task 4: Repurpose The Functional Test As A Load And Performance Test

The test we built in Task 2 operates a functional test by running the unit test with a single virtual user. Load and performance testing identifies the scalability index of a target host application by operating a test with multiple simultaneous concurrently running users. PushToTest repurposes functional tests as load and performance tests with changes to 2 instructions in the TestScenario. No changes are needed to the unit test to repurpose the test as a load and performance test!

In the TestMaker window use the File -> Open TestScenario command. Use the file selector to choose FlexFlashAMFTests/AMF_Load_Test.scenario
Click the Edit icon in the TestScenario Controller panel.
Set the test to be a load test in the General tab.

The above code tells PushToTest to operate a load and performance test at three levels of concurrently running simulated users (crlevel.) The test operates 2 users, then 4 users, and then 8.

This test repurposes the functional test as a load and performance test. The use case and options remain the same in this load test.
Click the PushToTest Run button and watch the results.

PushToTest operates the test in 2 concurrently running simulated users, then 4 users, then 8 users. The Real Time Scalability Index contrasts the Transaction Per Second (TPS) for each of the three user levels.

The Real Time Scalability Index shows the troughput of the application under test as the load increases. For example, when we double the number of users from 2 to 4 one would expect twice the number of transactions processed per second (TPS.) The Scalability Index is an immediate way to understand the scalability of the application and perform root cause analysis and mitigation of performance bottlenecks.

Task 5: Repurpose The Functional Test As A Business Service Monitor

Business Service Monitor testing enforces and proves a Service Level Agreement (SLA) by operating a test periodically. For example, a monitor runs a test every 30 minutes. TestMaker repurposes functional tests as a monitor without requiring any change to the unit test. Changing 1 instruction in the TestScenario is all it takes!

In the TestMaker window use the File -> Open TestScenario command. Use the file selector to choose FlexFlashAMFTests/AMF_Monitor_Test.scenario
Click the Edit icon in the TestScenario Controller panel.
Set the test to be a load test in the General tab.
This test repurposes the load test as a production monitor. The use case and options remain the same in this monitor.
Click the Run button and watch the results.

TestMaker's AMF protocol handler uses the OpenAMF - Java Flash Remoting library.

Additional documentation, product downloads and updates are at www.PushToTest.com. While the PushToTest TestMaker software is distributed under an open-source license, the documentation remains (c) 2011 PushToTest. All rights reserved. PushToTest is a trademark of the PushToTest company.