FlexAbility

I was recently asked to write up a summary pointing out some of the more interesting bits of Visual FlexUnit‘s code for a code review by a potential employer. As I wrote this I realized that I might as well dual-purpose these notes as a blog post. If you’re curious about how VFU works, read on.

Unless otherwise specified, all code is in VFU’s dev/vfu/visualflexunit/src/flex/ folder.

1. com.allurent.flexunit2.vfu.flexui.VfuTestRunner – This file includes comments that talk about VFU’s ‘tacked-onto-FlexUnit’ nature, resulting kludgishness, and potential next-step refactoring.

2. Take a quick look at VFU’s documention. I don’t suggest that you read the whole thing but, in particular, Step 2.B contains a sample test method that shows the sort of thing users would be writing.

3. com.allurent.flexunit2.vfu.framework.testsequence.
TestSequenceManager – One of the primary challenges of writing VFU was the combined result of these factors:

• We wanted test writers to be able to write clear, concise test methods like the sample method I just mentioned.
• Such methods inevitably result in multiple asynchronous processes, e.g. component rendering & file reading.
• FlexUnit has a mechanism for handling asynchronous processes, but can only handle one such process per test method.

A poor solution to this set of factors would be to ask test writers to write a chain of methods for each test, linked together with FlexUnit’s addAsync() mechanism. Ack!

Instead I created this manager class that creates and manages a queue of command objects, as requested by the user’s test code.

4. You might also want to take a look at some of the command classes in com.allurent.flexunit2.vfu.framework.testsequence.commands, especially AssertComponentMatchBaseline.

5. AssertComponentMatchBaseline includes a _judgmentStrategy:IBitmapMatchJudge private variable. The strategy object stored here is responsible for deciding whether the rendered component’s bitmap is close enough to a stored baseline bitmap to be visually indistinguishable. By default this variable holds an instance of com.allurent.flexunit2.vfu.framework.strategies.DefaultBitmapMatchJudge. Test writers have the option to write their own alternative strategies and pass them in. A simple example of using composition to allow flexibility.

6. /dev/vfu/vfuexampleTest/build.xml – Shows how we simply override a single Ant property in order to run automated visual tests. The build process is identical to the process used when running standard FlexUnit tests, except that we tell it to use a different MXML app template. Marty Frenzel showed me this elegantly simple approach.

7. /dev/tools/build-common-targets.xml – For the most part this is slightly-modified Antennae code. I added the build-visualflexunit and test-visualflexunit targets.

8. /dev/vfu/visualflexunit/template/testprojecttemplate/build.xml – VFU includes a bootstrap mechanism which makes it easy for users to create the framework for visual test projects. This file’s bootstrap-visual-test-project target copies files and uses Ant’s token replacement mechanism to insert appropriate project, file and folder names.