Vivisecting Media

Flexunit Testing Structures

I recently started a new Flex project and one of the goals was to really leverage Flexunit for creating automated unit tests for the core Framework that is being designed. My intention with using Flexunit (and any unit testing strategy) is two fold: One, the code I am working on at the moment is predominantly utilities and data processors that can’t really be run from the main system yet because the main system doesn’t fully exist. By creating unit test I can execute my code and verify that what I built actually does what I intend. Second, I want to create an extensive library of tests for the core Framework so that as the project proceeds the developers and QA have a basis for testing before a checking in code to make sure nothing was broken.

I am not going to delve into the details of Flexuint, there are plenty of starting points out there. What I want this post to focus on is how I structured the projects to provide a clean testing development process. To some of you this may be a “duh” article but for me it was like a light going off on how to create a clean separation of release code from test code.

In this example (see figure 1) we will set up two projects, one is the core framework: “james framework”, the second is for testing: “james unittest”. Framework is obviously where you do all you development. When you are ready to write a test, you will then create a test Class in the unittest project. Each of these projects should be kept in different paths in a source code management tool so that when deployment time comes around, only the release code is used.

The way the two projects are linked is through the source feature in FlexBuilder. Right click on the unittest project and choose “Properties” > “Flex Build Path” > “Source Path” > “Add Folder”. There you browse to the “com” folder of the framework project and select it. By linking in the framework as source to the unittest project you can then get all the hinting and compiling as if the framework project is part of the unittest project. You should also note that I use a different package name for my tests. This keeps them clearly separated as they are developed.

This separation is very important because often QA needs to create stub classes to test integration points or add assets that should never be checked into the deployed version. Speaking of stub classes, one of the challenges of whitebox testing is getting access to specific properties / methods that are often hidden. One way around this is to mark your class properties as protected or internal so that test classes can be developed that will extend the base class and then have access to the protected properties. This strategy helps prevents methods and properties from having to be set to public just so that QA can verify the value.

This is a really simple strategy that I have been very happy with so far. In the past we followed the typical testing example where the same project was used for both testing and development and we repeatedly had issues where test code was injected (or worse; required) during the build. I hope this helps you out!