FlexAbility

Here are a few UML (Unified Modeling Language) diagrams that show a bit about how Visual FlexUnit works.

All are simplified to enhance clarity.

This post is intended to complement my Highlights of Visual FlexUnit’s Code post.

1. TestCase Classes

When you use VFU to write visual tests you subclass VfuTestCase rather than TestCase. But VfuTestCase is a subclass of TestCase, so you still have access to all the standard TestCase functionality. This diagram shows an example test class, VfuExampleTests, which is included in the VFU download, and its two superclasses.

Also, note that VfuTestCase uses a TestSequenceManager instance. We’ll look more closely at this shortly.

2. TestSequenceManager & the TestSequenceCommand Classes

VFU uses the classic Command design pattern…

TestSequenceManager has an array holding zero to many TestSequenceCommand instances. All TestSequenceCommand instances also hold a reference to TestSequenceManager so that they can make calls back to it, including its commandFinished() method.

3. Sequence Diagram for TestSequenceManager & Some TestSequenceCommand Classes

Before we look at the sequence diagram, heres a sample visual test method from the VFU docs:

Note that we call multiple add…() methods in VfuTestCase.testSequence – its TestSequenceManager instance – then we call its start() method.

This sequence diagram is a simplified depiction of what happens when a very simple test method is run, on with just two add…() calls. Most add…() calls to TestSequenceManager create and add a singleTestSequenceCommand instance to its _testSequence array. The addAssertComponentMatchBaseline() call does this, as shown below. The addRefresh() method is unusual in that it creates and adds three. Once all TestSequenceCommands are created the manager starts to execute them.