patrickmowrer.com

Multiple thumb Spark Slider v. 0.1.3.

Sun, 07 Oct 2012 00:00:00 +0000

Some way-overdue bug fixes have been made to the multiple-thumb Spark slider component. Thanks to those reporting issues! Please let me know if there’s anything else that needs fixing; promise it won’t take another year. Find the new version on Github. Change list for version 0.1.3 below:

Fixed bug giving thumbs NaN value when min and max are set to same value.
Fixed bug where setting minimum and maximum at same time could limit either based on previous minimum/maximum value.
Fixed bug where clicking on track in a negative value range would cause null exception.

FlexUnit4-testing with morefluent-signals

Fri, 04 Mar 2011 00:00:00 +0000

Some time ago I wrote about improving the readability of asynchronous FlexUnit4 tests, which typically suffer from being broken up on multiple function blocks and from the terse method names of the Async helper class. To address it, I wrote a library of asynchronous matchers intended to be used with hamcrest-as3.

Soon thereafter, I was made aware of the existence of Kris Karczmarczyk’s excellent library morefluent, already addressing all of the issues I aimed to correct in my own library, and more. It has since become one of the swcs I always drop into my libs folder when I start a test project, along with other givens like hamcrest-as3 and FlexUnit4. Quite frankly, its a disgrace this library has only been downloaded some 60 or so times across its version history (according to BitBucket’s stats), but that probably says more about the prevalence of unit testing within the Flex/Flash community than anything else.

For my latest project, I’ve almost exclusively moved over to using as3-signals over Flash’s native events. However, morefluent only works with events, and there isn’t much in the way of alternatives. There’s a library wrapping FlexUnit4’s Async for use with as3-signals, as3-signals-utilities-async, enabling asynchronous signal testing, but writing tests with it is no different than using regular Async; the readability issues remain (by design, of course). Sacrificing test readability not being an option, I decided to marry morefluent with as3-signals-utilities-async, creating morefluent-signals.

To illustrate my point, this is how the first example from as3-signals-utilities-readme reads:

[Test(async)]
public function change_user():void
{
    var model:IModel = new SomeModel();
    handleSignal(this, model.changedSignal, verify_user, 500,  
        {name:"Tom", age:20});
    model.changeUser("Tom", 20);
}

private function verify_user(event:SignalAsyncEvent, data:Object):void
{
    assertEquals(event.args[ 0 ], data.name);
    assertEquals(event.args[ 1 ], data.age);
}

This is how the same example reads with morefluent-signals:

[Test(async)]
public function change_user():void
{
    var model:IModel = new SomeModel();
    model.changeUser("Tom", 20);
    after(model.changedSignal).assertOnArguments().equals(["Tom", 20]);
}

Here are a few more examples of how you can use morefluent-signals to assert that…

… an asynchronous signal was never dispatched:

[Test(async)]
public function asyncSignalWasNeverDispatched():void
{
    after(asyncSignal).fail();
}

… an asynchronous signal was dispatched with given arguments:

[Test(async)]
public function asynchSignalWasDispatchedWithArgs():void
{
    after(asyncSignal).assertOnArguments().equals([anything()]);
}

… a synchronous singal was dispatched x number of times:

[Test]
public function syncSignalWasDispatchedTwice():void
{
    observing(syncSignal);
    syncSignal.dispatch();
    syncSignal.dispatch();
    assert(syncSignal).dispatched(times(2));
}

… a synchronous signal was dispatched with given arguments:

[Test]
public function syncSignalWasDispatchedWithArguments():void
{
    observing(syncSignal);
    syncSignal.dispatch("string", 123);
    assert(syncSignal).dispatched(withArguments("string", 123));
}

Download morefluent-signals on Github and let me know what you think. I’m more than happy to address any issues you come across or considering any new features that makes your testing easier.

Multiple thumb Spark Slider v. 0.1.1

Tue, 22 Feb 2011 00:00:00 +0000

A new version of the multiple thumb Spark Slider is now available on Github. This version doesn’t add any new major features, but polishes up existing behavior. Regrettably, I’ve had very little time to work on it since releasing the first version; I hope to get to adding new features soon enough. For now, see the change-list below for updates in version 0.1.1:

Refactored HorizontalValueLayout and VerticalValueLayout into LinearValueLayout. This should enable easy creation of sliders between any two points, not just horizontal and vertical planes.
Added element alignment to value layouts, enabling the Slider thumb to be positioned over its value in any way desired. Constants classes provide convenience values for layouts, used by the HSlider and VSlider classes.
Renamed ThumbDragEvent to ThumbMouseEvent, and two if its types from BEGIN_DRAG and END_DRAG to PRESS and RELEASE respectively. This was done in order to be more consistent with the core Flex components and to better describe the event.
Made ThumbMouseEvents bubble such that event listeners won’t need to be added to individual thumbs, but can be listened to on the Slider component.

A multiple thumb Spark Slider component

Mon, 18 Oct 2010 00:00:00 +0000

After coming across a few community requests for a Spark Slider component with multiple thumbs, I decided building one would be a nice little side-project, perhaps with the added bonus of improving on my understanding of the Spark component architecture in the process. After all, how hard could it be? It’s just another couple of thumbs, right?

Turns out it wasn’t quite as easy as I had imagined, perhaps the reason there isn’t already a few of these floating around out there (or is there?). The Spark Slider is a nice component, but also a beast with a long inheritance chain (SkinnableComponent -> Range -> TrackBase -> SliderBase) and tightly coupled skin parts. Range is nothing but logic and would be a nice utility to make use of; sadly it inherits from SkinnableComponent. The layout is inexplicably baked into HSlider and VSlider, making it impossible to add any behavior up the inheritance chain without the need to re-create those classes (copy/paste, of course, just like skins!).

That said, perhaps there’s a good reason the original Spark component was written in that fashion. Either way, the implementation of this new Slider takes a lot of the existing Spark Slider code, cleans it up some and factors it out into more manageable bits. Layout is handled by a ValueLayout implementation, making it possible to create, for example, a CircularSlider without having to extend SliderBase. Some of the Halo Slider behavior is also there, like allowOverlap, and some isn’t, like having both value and values properties. I think it’s a good start, but I’ll let you be the judge. Check out the live comparison between the new Slider and those of Halo and Spark below.

Usage

As you’d expect, there are HSlider and VSlider convenience classes available. Neither define any logic, but are simply placeholders for a couple of style properties. For example, HSlider is equivalent to:

<ns:SliderBase skinClass="com.patrickmowrer.skins.HSliderSkin"  
dataTipOffsetY="-25" />;

The docs are currently absent, but hopefully it should be straightforward enough as I’ve tried to mimic desirable behaviors of the Halo and Spark components. From there, I intend to add additional functionality like Doug McCune’s Draggable Slider. For now, please feel free to download the component from the Github repository and let me know of any questions/issues.

Improving readability of asynchronous tests in FlexUnit4 using Hamcrest matchers

Thu, 19 Aug 2010 00:00:00 +0000

Inspired by the book Growing Object-Oriented Software, Guided by Tests, I’ve been working on improving how well my AS3/Flex tests read, both in terms of the test code itself as well as the diagnostics, the error description of failed tests. The goal is to make tests read more like plain English and, most importantly, better convey their intent. To this end, the Hamcrest library is excellent, providing matchers to make test code more expressive and expectations and errors more descriptive. Thankfully, Hamcrest has been around for some time for AS3, ported from Java by Drew Bourne.

After applying many of the techniques found in the book, I still found my tests lacking readibility when making assertions on asynchronous behavior. FlexUnit4 allows for asynchronous testing of events with the help of the Async class, and while the functionality is good, the tests generally don’t read so well. Bitten by the Hamcrest-matcher-writing bug, I decided to wrap the behavior of the Async class in Hamcrest matchers, creating a hamcrest-as3-async library. Though this may be stretching the definition of a matcher, I like what I’ve come up with thus far. Here are a few before-and-after examples to consider:

Event dispatchment

Even such a simple test as determining wheter an event has been dispatched doesn’t read anything like the fairly descriptive name of the test (i.e. the function name):

[Test(async)]
public function dispatchesAnEventOfTypeTest():void
{
   Async.proceedOnEvent(this, dispatcher, "test");

   dispatcher.dispatchEvent(new Event("test"));
}

Should it fail, Async’s error description isn’t overly informative:

Error: Timeout Occurred before expected event.

Alright, maybe I’m getting picky here, but we can do better. Instead, using a Hamcrest matcher:

[Test(async)]
public function dispatchesAnEventOfTypeTest():void
{
   assertAsynchronouslyThat(dispatcher, dispatchesEventOfType("test"), this);

   dispatcher.dispatchEvent(new Event("test"));
}

The test now reads more like the name of the test. Should it fail, it also does so more informatively:

Error: Expected: Event of type “test” was dispatched but: Event of type “test” wasn’t dispatched (timed out after <500> ms)

As you can see, the length of the timeout is mentioned in the error description, a value Async allows you to customize. Using a chained method call, beforeTimeoutAt, I’ve made it applicable to the matcher as well. The following sets the timeout to 1000 ms (instead of 500 ms by default):

assertAsynchronouslyThat(dispatcher, dispatchesEventOfType("test")
   .beforeTimeoutAt(1000), this);

Quirks

Before we go further, a couple of quick gotchas: 1. Like the Async class and unlike regular Hamcrest matchers, an asynchronous matcher must be declared before the event it listens for is dispatched. 2. You may not have noticed, but the last argument passed to assertAsynchronouslyThat is this. It must be passed an instance of the test case it is executing in as Async depends on that information. This is a bit ugly and surely a potential source of errors as it is easily forgotten and left off. Unfortunately, I’m currently not aware of a way around this.

Event data

Asserting on event data with Async is when readability really starts to suffer. A callback is required, forcing the test code to be broken up into two blocks. This means assertions are often being made in a second, separate function block, making the flow of the test difficult to follow. This can be remedied somewhat by nesting functions, but readability is still poor:

[Test(async)]
public function dispatchesAnEventOfTypeTestWithData():void
{
   Async.handleEvent(this, dispatcher, "test", assertDataIsEqualToValue);

   function assertDataIsEqualToValue(event:DataEvent, data:Object):void
   {
      assertThat(event, hasProperty("data", equalTo("value")));
   }

   dispatcher.dispatchEvent(new DataEvent("test", false, false, "value"));
}

The following is an identical test, only it’s written declaratively using an asynchronous Hamcrest matcher:

[Test(async)]
public function dispatchesAnEventOfTypeTestWithData():void
{
   assertAsynchronouslyThat(dispatcher, dispatchesEventOfType("test")
      .which(hasProperty("data", equalTo("value"))),this);

   dispatcher.dispatchEvent(new DataEvent("test", false, false, "value"));
}

Using the chained which method call, regular Hamcrest matchers can be added to match against the dispatched event.

Signals

Robert Penner’s AS3 Signals have become a popular alternative to the AS3 event system. With the help of the Signal-Async wrapper library, asynchronous matchers do Signals too!

Asserting on Signal dispatchment

[Test(async)]
public function dispatchesASignal():void
{
   assertAsynchronouslyThat(signalDispatcher, dispatchesSignal(), this);

   signalDispatcher.dispatch();
}

Asserting on Signal arguments

[Test(async)]
public function dispatchesASignalWithSpecificArguments():void
{
   assertAsynchronouslyThat(signalDispatcher, dispatchesSignal()
      .which(hasArguments("value", 123)), this);

   signalDispatcher.dispatch("value", 123);
}

The code

Asynchronous matching is only an experiment I’ve been making use of in my own projects. If you’re interested in it, please check it out on github. Please note that it depends on the most recent hamcrest-as3 code and isn’t compatible with its most recent SWC release, 1.0.2.

Part II: Using custom runners with Flash Builder 4's built-in FlexUnit4 support

Tue, 30 Mar 2010 00:00:00 +0000

Via asmock’s installation wiki, I stumbled upon a second way to link a custom FlexUnit4 runner into a Flash Builder 4 project: using a compiler argument.

Add the following to the “Additional compiler arguments” under “Flex Compiler” in your project properties:
-includes asmock.integration.flexunit.ASMockClassRunner

This way is probaby more straightforward than using a custom FlexUnitApplication, at least as long as you’re doing something simple.

Using custom runners with Flash Builder 4's built-in FlexUnit4 support

Tue, 09 Mar 2010 00:00:00 +0000

Recently, I’ve been trying to get mockito-flex to play nice with Flash Builder 4’s built-in FlexUnit4 support. For its part, mockito requires the use of a custom test runner class, MockitoClassRunner, to run any test case containing mockito dependencies, declared using FlexUnit4’s “RunWith” metadata tag:

[RunWith("org.mockito.integrations.flexunit4.MockitoClassRunner")]
public class MockitoTestCase

One caveat of custom runners is that they require being linked into the project:

RunWith(“fullyQualifiedName”)
– Used to identify a specific runner that should be used for this class. Common uses include specifying a class to use the Suite runner or Theory runner. The class specified must be linked into the project and must implement the IRunner interface.

(from: http://docs.flexunit.org/index.php?title=Metadata)

Without proper linkage FlexUnit4 will not be able to find the runner, throwing a runtime error such as the following:

Error: Custom runner class org.mockito.integrations.flexunit4.MockitoClassRunner should be linked into project and implement IRunner. Further it needs to have a constructor which either just accepts the class, or the class and a builder.

A simple way of linking the runner is to include a variable typed to the custom runner’s class inside of the class that initiates the test run. When using FB4’s built-in FlexUnit4 support, the class running the tests is FlexUnitApplication, auto-generated by FB4 after tests have been selected in the “Run FlexUnit Tests” dialog.

public class FlexUnitApplication extends Sprite
{
    private var mockitoRunner:MockitoClassRunner;

    public function FlexUnitApplication()
    {
        ...

Though the auto-generation of FlexUnitApplication is very convenient feature, automating the otherwise tedious, manual labor of supplying test cases to the runner’s “run()” method, its re-generated from scratch each time the test case selection changes, discarding any custom alterations, including the linkage variable. Manually adding the variable each time FlexUnitApplication is regenerated is a tedious and error-prone process in itself, but one that can thankfully be avoided using the following technique.

In FB4’s “Preferences” dialog, the one and only FlexUnit specific option lends itself very well to this situation. Here you can declare a custom application for FlexUnit4 to run instead of the one that’s auto-generated. Do note that using a custom application class does not stop the auto-generation of FlexUnitApplication, a fact that can be utilized to add a linkage variable that won’t get thrown away each time FlexUnitApplication is regenerated.

After a custom application name has been defined, the corresponding class needs to be created somewhere within the project hierarchy. This class should inherit from FlexUnitApplication and contain the linkage variable:

import org.mockito.integrations.flexunit4.MockitoClassRunner;

public class CustomFlexUnitApplication extends FlexUnitApplication
{ 
    private var mockitoRunner:MockitoClassRunner;

    public function CustomFlexUnitApplication() 
    { 
        super();
    }
}

Additionally, the custom application class needs to be made one of the runnable application files within the project (else FB4 will let you know so):

Now, when launching the “FlexUnit Tests” application via FB4, CustomFlexUnitApplication will be launched instead of FlexUnitApplication. As the former inherits from the latter, all of the auto-generated convenience is still available while keeping the linkage variable necessary to run the MockitoClassRunner.

Compiling custom AS3 metadata in Flash Professional

Wed, 03 Mar 2010 00:00:00 +0000

The use of custom metadata tags is becoming more commonplace in frameworks and libraries developed for the Flash platform. While many are targeted specifically for use with Flex and, by extension, the mxmlc compiler, others have uses outside of Flex. An example is FlexUnit4, which despite its name is easily used for testing AS3-only projects. Other testing frameworks that want to play nice with FlexUnit4, such as mock-as3 and flex-mockito, have incorporated custom metadata as well.

The mxmlc compiler accepts custom metadata with a command line option: keep-as3-metadata. As of Flex Builder 3 (mxmlc 3.0), custom metadata can be integrated seamlessly, rendering the additional option unnecessary most of the time. However, if you aren’t using the mxmlc compiler to compile your AS3 project, you may find that you also aren’t able to use custom metadata. For example, if you attempt to compile a FlexUnit4 test case in Flash Professional, you encounter an unexpected error:

initializationError Error: No runnable methods at org.flexunit.runners::BlockFlexUnit4ClassRunner/validateInstanceMethods()

The Flash Pro compiler does support some metadata tags, like SWF and Embed, but not custom tags that FlexUnit4 relies on, such as Test. As a result, all unrecognized tags are thrown out during compilation, in this example stripping the FlexUnit4 test case of any and all Test tags. When FlexUnit4 then attempts to run the test case, it finds nothing to run, throwing the error above.

As far as I know, Flash Pro doesn’t let you add command-line arguments to its compiler, but the good news is that there is a simple workaround to this problem, albeit a subtle one. By checking “Export SWC” in the “Publish Settings” dialog, all custom metadata is left alone during compilation.