ActionScript

A couple of days ago, I complained about FlexUnit's Theories. Well, with a bit of encouragement from @drewbourne, I broke down and wrote a proper parameterized testrunner:

    [RunWith("utils.testrunners.ParameterizedRunner")]
    class AdditionTests {
        public static var numbersToTest:Array = [
            [1, 2, 3],
            [4, 5, 9],
            [-1, 1, 0]
        };

        [Parameterized("numbersToTest")]
        public function testAddition(a:int, b:int, expected:int):void {
            assertEqual(a+b, expected);
        }
    }

And that code will do exactly what you'd expect: run three test cases, one for each of the inputs. If one test fails, the others will still run. Helpful error messages will be provided when a test fails.

The source can be downloaded from: http://gist.github.com/299871 (and it will be getting a new home when ever I get around to releasing all of my AS utilities)

Look useful? Give it a try and tell me what you think – I'd love to know.

I've just been playing around with FlexUnit 4's nifty new "Test Theories"… And I have come to the conclusion that, right now, they are basically worthless.

Here's why:

• They aren't documented. At all. There are approximately two examples on the internet, and the wiki page is a joke. Nothing explains what algorithm is used to calculate which DataPoints are applied to which theories.
• They make test error messages less helpful. If a a theory fails, instead of getting a helpful error message like "Theory `checkUrl("this is a bad url")` failed with message: could not determine protocol", it gives a message like this: "checkUrl urls[1]". Yea, thanks guys.
• They don't do anything "cool". At all. It would be cool if, given five data points, five distinct tests would be generated. It would be cool if one data point could fail while others succeed. Heck, anything which would make them better than a for loop would be cool. But, alas…

So, don't waste your time on Theories just yet. For now, just use a for loop:

[Test]
public function runTestsOnData():void {
    for each (datum in testData)
        doSomeTest(datum);
}

Or, if you want to test the cartesian product of a set of data, use my handy cartesian product function:

[Test]
public function runTestsOnCartesianProduct():void {
    for each (data in cartesian_product(testData0, testData1))
        doSomeTest.apply(this, data);
}

Followup: as Alan (see comments) said, what I really want is a parameterized testrunner. So I've gone ahead and written one. See my post on a Parameterized Testrunner for FlexUnit.

(alternate title: The "Fail Early, Fail Often" Principle in Action)

I would like to award Adobe the "best ever implementation of indexOf". Ready for it? Here it is:

override flash_proxy function callProperty(name:*, ... rest):* {
    return null;
}

This beauty can be found in mx.collections.ListCollectionView.

And the kicker? The function's documentation:

/**
 *  @private
 *  Any methods that can't be found on this class shouldn't be called,
 *  so return null
 */

The author clearly knew that unknown methods* shouldn't be called… But instead of doing something sensible – like throwing an exception – they do something wholly nonsensical and return null. Or, of course, they could also have left the function unimplemented, which would result in a strange and unhelpful exception… But, of course, I would expect nothing but the best from the Flex standard library.

Next up: why implicit conversions from null to int are always wrong.

</rant>

*: the magic callProperty method is called on subclasses of Proxy when a method can't be found. For example if bar is not a method of foo, executing foo.bar()will call foo.callProperty("bar").

PS: Instead of calling indexOf, I should have been calling getItemIndex.

If you're anything like me, you cringe every time you think about implementing a popup menu in Flex: the options, PopUpButton and PopUpMenuButton, are both terrible.

For example, PopUpButton makes you jump through the hoops of creating a Menu and PopUpMenuButton forces you to create an event handler just to get the currently selected item.

Well, cringe no more! I've done a bit of hacking on the PopUpMenuButton to make the most common use-case, "showing a list of options", a little bit less painful by adding a 'selectedItem' field:

    <mx:XML id="colors">
        <colors>
            <color name="Red" rgb="0xFF0000" />
            <color name="Green" rgb="0x00FF00" />
            <color name="Blue" rgb="0x0000FF" />
        </colors>
    </mx:XML>
    
    <HelpfulPopupMenu id="colorMenu"
        dataProvider="{colors}"
        labelField="@name"
        showRoot="false" />

    <mx:Label
        color="{XML(colorMenu.selectedItem).@rgb}"
        text="You've chosen: {XML(colorMenu.selectedItem).@name}" />

Which can also be used to set a temporary default option:

    <mx:Script><![CDATA[
        var people:Array = [
            { name: "Bob", age: 16 },
            { name: "Alice", age: 42 },
            { name: "Jo", age: 31 }
        ];
        
    ]]></mx:Script>
    
    <HelpfulPopupMenu id="peopleMenu"
        dataProvider="{people}"
        labelField="name"
        selectedItem="{ { name: '(select a person)', age: null } }"
        showRoot="false" />

    <mx:Label
        visible="{ peopleMenu.selectedItem.age !== null }"
        text="That person is { peopleMenu.selectedItem.age } years old." />

Useful? I'd like to hope so.

You can see a demo by clicking the image below (sorry, I don't actually know the first thing about embedding SWFs into HTML, and I don't feel up to learning right now):

And you can download the source (which is MIT licensed) from more or less the same place: http://wolever.net/~wolever/HelpfulPopupMenu/.

Also, this is a small part of a larger library of helpful ActionScript utilities which I'm going to be releasing… At some point.

Neil Webb's post on filtering an ArrayCollection on multiple property/values reminded me of how I recently solved exactly the same problem using Hamcrest-AS3.

So, you know the story: you've got an ArrayCollection that's full of, say, Laptops, and you want to filter it by, say, price, size and (of course) color.

Because you're a good programmer you always try to do the simplest thing that could possibly work first, and end up with a function something like this:

function laptopFilter(laptop:Laptop):Boolean {
    if (laptop.price > appliedFilters.maxPrice)
        return false;

    if (laptop.size > appliedFilters.maxSize)
        return false;

    if (laptop.color != appliedFilters.preferredColor)
        return false;

    return true;
}

Cool - that defiantly works, and it's pretty simple.

"But wait a second", you're thinking, "what happens when the rules get more complex? That function is quickly going to loose its simplicity!"

Enter, Hamcrest.

Hamcrest is a library of "matchers" which are often used to build unit tests. Here is a quick example of a unit test written with Hamcrest:

[Test]
function testApplePicker():void {
    var apples:Array = ApplePicker.pick("granny smith");
    assertThat(apples.length, greaterThan(4));
    assertThat(apples, everyItem(hasPropery("color", "green")));
}

But, of course, there is no reason that these same matchers shouldn't be used for other things too.

Other things like, say, filtering an ArrayCollection:

var filters:Array = [
    hasProperty("price", greaterThan(1000)),
    hasProperty("color", either("red").or("blue").or("green")),
    hasProperty("size", between(10, 15))
];

var laptopFilter(laptop:Laptop):Boolean {
    return allOf.apply(null, filters).match(laptop);
}

Of course, I've hard-coded the values in this example, but it doesn't take much creativity to imagine how they could be dynamically generated, keeping the code nice and simple while still allowing for complex rules.

So, that's how I filter ArrayCollections

Are you working with a proprietary .swc? Does it have lots of bugs? Did the authors, in all their infinite wisdom, decide to hide those bugs in private methods, so you stand no chance of being able to fix them? Well, friend, let me show you how to fix that.