Terminology

Before diving too much further into this process, we should discuss some terminology. In dpUInt, we deal with test suite, test cases and test methods. These are represented by the classes named TestSuite, TestCase and TestMethod in the dpUInt framework.

For our purposes:

Test Method

A TestMethod is the smallest unit of the testing framework. A test method exercises code and checks an outcome. At the end of the test method we generally make an assertion, stating that we expect the outcome to be in a specific state. We might expect a value to be true or false, null or not null, perhaps even equal to another variable. If the assertion is valid, the test passes. If the assertion does not logically work (we specify it should be false but it is really true), the test fails.

Regardless of the complexity of the test method, it may setup several conditions, exercise several pieces of code, or even wait for an asynchronous event; it should ultimately make only a single assertion. This is a point of contention and many disagree, but ultimately a single assertion per method ensures the best granularity in resolving test failures, among other benefits.

Test Case

A TestCase is a collection of TestMethods that share a common test environment. Each TestCase has a setUp() and tearDown() method which can be overridden to create a specific environment for your TestMethods. So, for example, if you wanted to write a series of TestMethods to test the Flex Timer class, they could all exist in a single TestCase. In the setUp() method you would create a Timer instance to test with. In the tearDown() method, you would stop that timer and remove references so it can be garbage collected. If your TestCase has two TestMethods, the dpUInt framework would execute the TestCase in the following way:

setUp();
testMethod1();
tearDown();
setUp();
testMethod2();
tearDown();

The setUp() method is executed before each of your TestMethods and the tearDown() method is run after each TestMethod. All TestMethods in your TestCase need to begin with a lower case ‘test’, so testTimer and testEvent are valid TestMethods, but TestOne and oneTest are not. There is no formal limit on the number of methods that can be contained in a single TestCase.

Test Suite

Finally, a TestSuite is a collection of TestCases. The dpUInt itself has a FrameworkSuite which contains TestCases pertaining to different aspects of the library, such as asynchronous tests or UIComponent tests. Each of those TestCases then contains TestMethods which share a common setup to be executed.

Test Runner

Finally, we need a way to run tests. If you are running your tests on your development machine, you may want a user interface that reports errors and failures visually. If the tests are running on a server in an automated build environment, the user interface may not matter and an XML style output may be significantly more helpful.

dpUInt does not prescribe a user interface, but rather provides a series of components which can be used together in either a Flex or AIR project to provide as much of a user interface as required. Further, there are AIR specific components which can be used for advanced features such as automated test running on file change or XML file output compatible with automated build systems.

There is a very simple SampleTestRunner available for download with this project. This sample test runner uses several of these components to create a tree-based test browser and a visual progress bar which can be clicked to dive down for further information on a test success or failure.

To use this sample test runner:

1. Create a new Flex or AIR project;
2. Copy the SampleTestRunner.mxml into that project;
3. Go to the project’s properties, and then the Flex Build Path option;
4. Click on the Library Path tab;
5. Click the Add Project button;
6. Choose the library project you created with the download code;
7. Build your Flex project.

This sample test runner runs the tests created for the framework out of the library project. Other pages in this Wiki will explain how to create your own tests.

Previous | Next