Code Kills

Ok guys, it's pretty simple: if you're working in a Turing-complete environment and you've got paths which start with a '/', you're doing it wrong. Very wrong!

Todays offender: WSGI scripts.

Here's the first line of a common WSGI script:

app_path = '/path/to/application'

See a problem there? That's right, the absolute path!

How could this be solved? Simple: put the WSGI script in /path/to/application, then get the app_path using: app_path=os.path.abspath(os.path.dirname(__file__)). Problem solved.

</rant>

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.

Update

Since this article was written, parameterized tests have been added to FlexUnit core. The documentation is over on the FlexUnit wiki: http://docs.flexunit.org/index.php?title=Parameterized_Test_Styles

And this is the above test, using the FlexUnit syntax:

 
    [RunWith("org.flexunit.runners.Parameterized")]
    public class AdditionTests {        

        public static var numbersToTest:Array = [
            [1, 2, 3],
            [4, 5, 9],
            [-1, 1, 0]
        };


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

tl;dr: learn what Alpha can do, add a keyword search for it.

Remember Wolfram|Alpha? Wolfram's attempt at a computer knowledge engine that got a little bit of hype, then drifted into obscurity?

Well, it has been making me pretty happy recently, and maybe it can make you happy too. Here's my trick:

First, learn what it can and can't do: it won't help much with a broken xorg.conf… But if you need to convert units (especially units of storage), get information about a date, compare stock information or do anything with a mathematical equation, Alpha is incredible.

(yes, there is nothing there that's unique to Alpha… But that's not the point. The point is that, once you know what it can do, you can, on the first try, get the information you need. There's no looking through Google search results (even Google's calculator takes a couple of tries (compare: alpha: 4 CAD in USD).)

Second, make it really, really easy to use: add a keyword search (if you're in Safari, use Stand) so searching Alpha is just as easy as searching the rest of the Internet:

Then just start using it

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.