Basic terms and concepts

Before diving too much further into this process, we should discuss some terminology.
In FlexUnit 4, we deal with test suites, test cases and test methods. Unlike previous versions of FlexUnit, there is no need to extend specific classes to define the suites, cases or methods. This will all be done by marking your tests with .

For our purposes:

Test Method

A TestMethod is the smallest unit of the testing framework. A test method executes code and checks an outcome. At the end of the test method we generally make an assertion, stating our beliefs about the state of this particular test method if all worked as planned. We might expect a value to be true or false, null or not null, perhaps even equal to another variable, or simply not in a list of acceptable values. If the assertion is valid, the test passes. If the assertion does not represent reality (we specify it should be false but it is really true), the test fails.

Though a single test method may setup several conditions, exercise several pieces of code, or even wait for an asynchronous event, it should ultimately make a minimum number of assertions. When we make assertions in a test case, if any assertion fails, the entire test fails. Therefore, the fewer number of assertions we make in a single test method, the more granular the method and hence the easier to determine what actually failed.

When using FlexUnit 4, your tests names do not need to follow any convention at all. You can name things as you see fit.

public function thisShouldPass():void {}
public function checkIfThisFails():void {}

In FlexUnit4, your methods must also be decorated by a piece of [Test] metadata . For example:

[Test]
public function fails2():void {}

This allows you to control your tests in more granular detail and provide additional information about why they exist. For example:

[Test(description="Test is supposed to Fail",issueID="0012443")]
public function fails2():void {}

The [Test] metadata allows you to embed descriptions of the test as well as other useful information for reporting, such as the issueID or bug number that this test addresses. FlexUnit 4 does not dictate what information can be present in the test Metadata . It simply preserves all attributes that you specify within the [Test] Metadata tag.

You can decorate tests with more than one piece of metadata. For example, the [Ignore] Metadata tag may also be added to a test method to skip a particular test. Descriptions can still be added to [Ignore] tags so it is suggested that you include a descriptive reason of why the test was removed for future reference.

[Ignore("Not Ready to Run")]
[Test]
public function multiplication():void {}

Test Case

A TestCase is a collection of [TestMethod|TestMethods] that share a common test environment. When using FlexUnit4, each \[TestCase\] can have a [\[Before\] | FlexUnit Metadata#Before ] and [\[After\] | FlexUnit Metadata#After] metadata tags that can be used to decorate methods you want to run before and/or after each test method.  These metadatas simulate the {{ setUp()}}  and {{ tearDown()}}  methods of [Fluint | http://fluint.googlecode.com/] and FlexUnit .9 | [http://code.google.com/p/as3flexunitlib/]. So, for example, if you wanted to write a series of [TestMethods| FlexUnit TestMethod] to test the Flex Timer class, they could all exist in a single TestCase. In the method decorated with [\[Before\] | FlexUnit Metadata#Before] you would create a Timer instance to test use in your tests. In the method decorated with [\[After\] | FlexUnit Metadata#After], you would stop that timer and remove references so it can be garbage collected.
Additionally, you may decorate any number of static methods per class with the medatadata [\[BeforeClass\] | FlexUnit Metadata#BeforeClass ] and [\[AfterClass\] | FlexUnit Metadata#AfterClass].  These methods will be run once per test class.

For example, if your TestCase has two [TestMethods| FlexUnit TestMethod], the FlexUnit4 framework would execute the \[TestCase\] in the following way:

1. [BeforeClass]
2. [Before]
3. [Test]
4. [After]
5. [Before]
6. [Test]
7. [After]
8. [AfterClass]

\*The [\[Before\]| FlexUnit Metadata#Before] method is run before every \[TestMethod\] and the [\[After\]| FlexUnit Metadata#After] method is run after every [TestMethod].

'''Note:''' In a TestCase tests may be executed in ANY order. If you would like to specify an order to the tests, you may do so, see order for instructions on how to do so.

Test Suite

Finally, a TestSuite is a collection of TestCase and possibly other TestSuite. A test suite is a simple class marked with a [Suite], and [RunWith("org.flexunit.runners.Suite")] Metadata tags. The tests and other suites that you want to have run inside this suite must be declared as public (and only public) variables. For example:

[Suite]
[RunWith("org.flexunit.runners.Suite")]
public class SampleSuite
{
     public var otherSuite1 : SampleOtherSuite;
     public var test : SampleTest;
     public var test1 : SampleAsyncTest;
}

• If you feel comfortable enough with these concepts you can feel free to move on to the next step or see Advanced Terms

Previous | Next