Unit testing and Test Driven Development (TDD) for Flex and ActionScript 3.0

Writing the first test

I'm going to plagiarize (with permission) the example used by Simon Whacker to demonstrate as2lib's unit testing, because it was particularly clear and easy to understand.

We are going to create an application for a bank, and our first requirement is to allow the creation of a new account.

The first question to ask yourself is: When creating a new account, what should happen? Well, not much. Despite my best wishes, whenever I open a new account, it always starts off empty. How do I know that for sure? Well. I know because I can check my balance. So, when I open a new account and check my balance I should have £0.00 in there. Okay, we have our first test.

Remember, in this tutorial, we write our test before we write the code in our class, and this is how it works:

In AccountTest.as, underneath our static "suite" method, paste in this code:

public function testNew():void{
    var account:Account = new Account();
    assertEquals("Expecting zero account balance", 0, account.getBalance());
}

Note: In some frameworks all tests must start with the prefix "test." With FlexUnit, this rule doesn't seem to be enforced, but for consistency I recommend doing so anyway. One reason to require any test method to start with "test" is that you can then shortcut the suite creation process. Simply introspect a class and any function that starts with "test" is considered a test.

In this case, you are testing the creation of a new account and so the method is called testNew.

As you can see, you create a new instance of the Account class, and then use an assertion method called assertEquals.

There are various types of assertion, but assertEquals basically checks that the two values passed in are ... [drum roll] ... equal. The eagle eyed among you may have noticed I am actually passing in three values:

1. The first value is optional. It is a String and it should clarify the outcome you are looking to satisfy. In this case: "Expecting zero account balance."
2. The next value is 0.
3. The last value is a call to an, as yet non-existent, method of our Account class called getBalance(). I will write this in a moment.

Overall, this assert specifies that you want the value returned from getBalance() to equal zero.

Note: TestCase extends Assert, so there is no need to import the Assert class in order to use these assertion methods.

All you have to do now is add your test to the test suite.

Amend the static suite function in the AccountTest class to look like this:

public static function suite():TestSuite{
    var accountTS:TestSuite = new TestSuite();
    accountTS.addTest(new AccountTest("testNew"));
    return accountTS;
}

You can see from the above code that I use the addTest method to add the test to the TestSuite. The object passed in is actually an instance of AccountTest (in other words, the class you are in). The name of the test to run, gets passed in as a String...

If you remember, the constructor for AccountTest looks like the following code:

public function AccountTest(methodName : String){
    super(methodName);
}

It accepts the methodName of the test, and passes it on to its super class.

Note: This is the way I first learned to test, but you don't have to do it like this. The framework will automatically find all "test" methods in a TestCase if you pass the class reference to the constructor of a TestSuite.

Test It!

Okay, the setup is done. It's time to test.

If you think back to the Test-Code-Simplify cycle of eXtreme Programming that we looked at earlier. The first couple of stages were:

• Write a single test.
• Compile it. It shouldn't compile, because you haven't written the implementation code it calls

You've written a test, so try and compile the project.

Figure 1. The Errors window

The Flex Builder Problems pane should also be reporting the following error:

"Call to a possibly undefined method getBalance through a reference with static type Account."

Great! That's what we want. You haven't written getBalance() yet And so you should quite rightly have a compiler error.

Note: If you actually choose to ignore the error and run the application anyway, you will see the TestRunner, and the test will actually pass! I didn't expect this to happen so be aware of it. It is fine to ignore Flex Builder warnings (in fact, the kind of tests you'll do will probably cause a few warnings) but don't ignore compile-time errors.

From further research, I found out that the test passes based on the last time you saved. So if you saved an empty test method, it would work; or, if you saved the empty testcase it would run and report no failures. When there are compiler errors, a new SWF file doesn't replace the old SWF, so you are in fact running the old SWF file.

Now take a look at the next two steps in the Test-Code-Simplify cycle:

• Implement just enough code to get the test to compile.
• Run the test and see it fail.

Amend the Account class to look like this (additions are highlighted in yellow):

package
{
    
    public class Account
    {
                private var _balance:Number;   
		public function Account(){
            
        }

       public function getBalance():Number{
             return _balance;
         }
    }
}

You now added your getBalance() method, which returns _balance, and you have also declared this variable called _balance (intended to hold our account balance amount of course), but _balance hasn't been initialized with a value yet. Compile, and you should see something like the following:

Figure 2. The TestRunner GUI

This error is a good thing! Here we can see the test that failed (testNew) and why it failed. The big red bar would be green if the test had passed.

Now you know your TestRunner is working properly. You know the test should have failed, you know your test did fail, and you know why it failed.

The TestRunner tells us that it expected a value of zero but received a value of NaN (Not a Number) which is what ActionScript 3.0 returns (variables typed as Number and not assigned a value are returned as NaN in ActionScript 3.0).

Continuing on, the next two steps in the Test-Code-Simplify cycle are:

• Implement just enough code to get the test to pass
• Run the test and see it pass

All you need to do now is give _balance an initial value of zero. Change your Account class's constructor to look like the following:

public function Account(){
    private var _balance:Number = 0;
}

Now run the test:

Figure 3. The test succeeds in the All Tests tab

Bingo. The bar is green. Here we are viewing the "All Tests" tab in the left pane, which shows that the testNew test has passed. You know it passed for the right reasons too, because you saw it fail when conditions were wrong.

The final two points in the Test-Code-Simplify cycle are:

• Refactor for clarity and "once and only once"
• Repeat

There's little need to refactor here, and so on with the next test.

Onwards and upwards

You've completed your first test—the hard part is over with. Take a break if you're exhausted because in order to see the real value of TDD we are going to implement a couple of extra tests. Most of the following code will be copy and paste with little need for additional explanation, so it shouldn't take long to get to the end now

Page 3 of 4

Previous Page

Next Page