Flexunit 4.x was designed to address many of the shortcomings of available Flex testing frameworks while enabling the extensibility needed by an evolving Flex community.
After completing this lesson, you should be able to:
In this unit, you will learn about the following topics:
FlexUnit 4.x is an extensible testing framework designed to provide unit and integration testing to its users. It was designed with several important goals in mind:
It achieves these goals through the use of several concepts referred to as runners, rules and listeners which you will explore in this unit.
FlexUnit is simply a testing framework responsible for executing user-created tests. It neither has a user interface for reporting the failure of specific tests to its users nor a way to launch a new test run. Instead, FlexUnit provides simple integration points for other tools and applications to use its capabilities and monitor the results.
This integration occurs mainly through the concept of listeners. Listeners allow an external class to register with the FlexUnit framework and receive progress notifications as tests progress. This progress information includes key data such as when a test begins, ends and how much time it took to execute. It also provides information about the success and failure of each test, with additional information provided about the cause of any failure.
Developers can use this information to provide simple visual representations of test status, such as the UIListener project, or complex interactive pieces. The Adobe Flash Builder 4, IntelliJ and FDT integrated development environments have all used this same technique to provide advanced testing integration to their users.
It should be noted that the FlexUnit team only maintains the testing framework and directly associated projects. Features and continuing integration into the IDEs mentioned above is solely at the discretion and hard work of teams at these companies.
A major goal of FlexUnit 4 was the ability to add new testing features in the future without the need for another rewrite. Further, it was important that developers be able to add new testing features for their own specific use cases that they may not be able to share nor wish to contribute back to the project. FlexUnit 4 provides this capability via two concepts: runners and rules.
A runner is a class which contains the necessary functionality to find and execute tests in a specific class. As you will continue to learn throughout this course, there are many types of tests ranging from simple static tests to those requiring parameters and data points.
With FlexUnit 4, developers are allowed to create their own runners for any unique circumstance present in their environment and register that runner with the testing framework. This allows a developer to replace the specific functionality around test execution but still maintain all of the integration with tools and IDE provided by the FlexUnit team.
Creating an entirely custom runner is a powerful but complex feature of FlexUnit. However, if you simply need to add additional features to the existing FlexUnit runners, you can use a concept called rules.
Rules allow you to 'bolt-on' additional functionality to the existing runners, giving developers the opportunity to execute additional code before and after tests or add extra layers of evaluation and comparison not present in the existing framework.
Later in this course you will use a rule implementation to handle mocking of objects during testing.
While FlexUnit 4 provides significant new features, there are many thousands of unit tests written in the original FlexUnit and Fluint framework which developers are rightfully reluctant to migrate. To allow developers access to these new features, it was necessary to run the existing unit tests precisely as they executed today without changes to timing or other errors that could be introduced in a port of these technologies.
Instead, FlexUnit 4 uses the concept of the runner, explained above, to wrap the entire FlexUnit .9 and Fluint frameworks. This means that when FlexUnit 4 encounters a legacy test, it instantiates the original framework and uses that object to execute that particular test.
Quite literally, the entire FlexUnit .9 and Fluint frameworks are available inside of FlexUnit 4.x as runners which can be used at anytime to ensure that legacy tests are executed precisely as originally intended.
Although FlexUnit 4.x is intended to be extended by developers as needed, it still ships with a rich set of available test runners. These runners provide the ability to run a variety of test types. Standard runners include:
* Note: Due to the nature of Fluint, this runner is only available with the Flex-specific version of FlexUnit.