Unit 12 - Running Tests from Different Versions

Download Download Unit Project Files

Throughout this course you have been introduced to new types of runners for FlexUnit 4. The first runner you used ran basic FlexUnit tests. The proper name for that runner is the BlockFlexUnit4Runner. Next you learned about the Suite runner and more recently the Theories and Parameterized runner.

This lesson introduces two additional runners, the runner for FlexUnit .9 tests and the runner for Fluint 1.x tests.

Objectives:

After completing this lesson, you should be able to:

Topics

In this unit, you will learn about the following topics:

Running a FlexUnit .9 test

Running a Fluint 1 test

Understanding a runner

Runners are a major component of the extensibility layer of FlexUnit 4. They facilitate creating entirely new test types that can gain the benefit of FlexUnit 4.x integration without rewriting the entire code base.

A runner is just a class that implements an interface that FlexUnit 4 can understand. FlexUnit 4 includes runners for FlexUnit .9, Fluint 1, FlexUnit 4, Suites, Theories, and Parameterized tests.

Runners operate through a token system. At the start of a test run, a runner is provided a token. To simplify things a bit, you can think of the token like the silver baton used in a relay race. The system asks each runner in turn if it can handle the tests contained within an individual class. If the runner can, it passes a token to that runner which now becomes the active runner.

That runner in turn hands the token to any sub-runners as needed (think Suite which just contains classes to be run by other runners). Once the test completes it passes the token and result back to whomever provided it with the token. In this way, tests are recursively executed until the token makes it all the way back to the framework itself.

Understanding how FlexUnit 4.x can work with multiple runners

The token system within FlexUnit 4 allows the framework to understand different runners without knowing the actual implementation of the runners. As long a runner notifies FlexUnit 4 through the token that a test finished and what the result was the framework does not care how the runner made that decision.

The metadata decoration "RunWith" notifies FlexUnit 4 which runner to use for the tests contained in the class. If no runner is specified FlexUnit 4 will attempt to derive the correct runner from a series of possibilities.

You can create new runners from scratch or extend existing runners to add functionality. The parameterized runner is an excellent example of adding additional functionality to the base runners used by FlexUnit.

Walkthrough 1: Creating a mixed Suite of Tests

In this walkthrough you will perform the following tasks:

Import a new test

  1. Import the FlexUnit4Training_wt1.fxp project from the Unit 12/Start folder. Please refer to Unit 2: Walkthrough 1 for instructions on importing a Flash Builder project.


    Examining the FlexUnit .9 tests

  2. Open the TestAssert.as file in the fu1 package in the tests folder.

    As you examine the class file you will notice a few differences about these test methods. The TestAssert class extends from the TestCase class. The TestCase class was the base class for all tests in FlexUnit .9.

    public class TestAssert extends TestCase {      
      public function TestAssert( name : String = null ) {
         super( name );
      }

      ...
}

    The class constructor in FlexUnit .9 can be used to provide a name for this test in certain circumstances. In this test it does nothing more than call its super() method. FlexUnit 4.x tests do not descend from any particular class.

    Metadata is not used to distinguish tests and fixture from normal methods. Every method in this case prefixes the word test to its name. Take a look at the testMatch() method:

    public function testMatch() : void {
    Assert.assertMatch(
         /fr.*gt/,
         "feeefrbgbgbggt" );

    Assert.assertMatch(
         /.*@adobe\.com/,
         "xagnetti@adobe.com" );

    Assert.assertMatch(
         /.*@adobe.?com/,
         "xagnetti@adobevcom" );

    try {
       Assert.assertMatch(
         /.*@adobe\.com/,
         "xagnetti@adobevcom" );             
    }
    catch ( e : AssertionFailedError ) {
       assertAssertionsHaveBeenMade( 4 );

       return;
    }
    fail();
}

    There are separate Assert classes in FlexUnit 4 and FlexUnit .9. Both have static methods for making assertions. When running tests in FlexUnit 4 you can use either of these classes, to help maintain backwards compatibility.

    FlexUnit 4.x Assert: org.flexunit.Assert

    FlexUnit 1 Assert: flexunit.framework.Assert

    For catching errors, FlexUnit 1 uses try, catch statements. FlexUnit 4.x uses expects="" metadata for the same kind of test.


    Run FlexUnit 1 tests

  3. Open the FlexUnit4Training.mxml file.

  4. Within the <fx:Script> block there is a function named currentRunTestSuite(). Add a line that calls the testsToRun.push() method with the argument TestAssert.

    import fu1.TestAssert;

import math.testcases.CircleSuite;

public function currentRunTestSuite():Array {
    var testsToRun:Array = new Array();
    testsToRun.push( CircleSuite );
    testsToRun.push( TestAssert );
    return testsToRun;
}

    If you did not use code-completion, add the import statement for fu1.TestAssert at this point.

  5. Save and Run the FlexUnit4Training.mxml file.

    If FlexUnit4Training.mxml ran successfully you should see the following output in your browser window:

    TestsPassed

    Figure 1: FlexUnit tests passed

    And in the FlexUnit Results tab, you will see the results of all tests:

    ResultsWindow

    Figure 2: FlexUnit results window

Summary

Navigation