Rough Sea Games

Hello, welcome back and a happy new year to all readers from me as well!

Today, we are going to shed some light on our unit-testing process. It is one of our vital safety parts to ensure that our development process is still on track and that we are not breaking anything.

Before we started the project, I did some research on unit testing with AS3 on the web. I stumbled upon AsUnit at http://www.asunit.org by Luke Bayes and Ali Mills. I integrated their framework into our newly set-up project and we were able to start coding right away. Just now I realized that the  tutorial to set up AsUnit with FlashDevelop disappeared from the web. So, I decided to quickly assemble a new tutorial. You can find it at my web page http://www.ruelke.net.

When we started using it in real-life, we discovered a few minor issues. Consequently, I added and changed a couple of things over time, which transformed AsUnit into our very own version.

1. Process: Run tests first: if one fails do not start project code
2. Extension: Our Asserts can be checked
3. Extension: Controlling the debug output

Ok, let’s explore these things a little further:

1. Run Tests First: If One Fails Do Not Start Project Code

Out of the box, AsUnit just doesn’t do anything after it has finished the tests. We all are regular game programmers that have used C++ before. So our unit-testing experience revolves around UnitTest++. I tried to get AsUnit to behave as similarly as possible. Accordingly, AsUnit needs to do the following:
- Start and Run the tests
- Check the result
- Continue with the game code if everything was correct

To do this, I extended the TestRunner-constructor with another parameter: a function pointer (callback). The callback is called within the TestRunner’s testCompleteHandler-function if the unit tests passed successfully. Then the callback takes care of continuing with the game — starting the game loop, loading assets and so on.

2. Our Asserts Can Be Checked

It is important to integrate our assert-handling into the testing process. You may remember my posts about assert-handling a while back (http://blog.rough-sea.com/category/methodology/). It is possible to use our debug class’ HasAsserts()-method, which returns true if an assertion failed, to check if an assertion actually fails as expected in a test case. The AsUnit framework has a class called Assert, which contains all checking methods used in the tests. By using what’s already there (like the assertTrue method), I could realize the check for assertions in a very simple way :

/**
 * Asserts assertions.
 * Usage: assertError(m_object.ErroneousMethod())
 * If assertion does not fail an AssertionFailedError is thrown
 * with the given message.
 */
static public function assertError(...args:Array):void
{
    assertTrue("Assertion failed to fail!", Debug.HasAsserts());
    // clear the asserts so there is
    // no interference with other tests
    Debug.ClearAsserts();
}

3. Controlling The Debug Output

A lot of our classes, especially the state machines, contain automated debug output. When running our tests, this debug output is overwhelming … and useless as well. All of the console output goes through our Debug class. So I added a flag that is able to disable the sending of messages to the console. This flag is activated right before the tests and deactivated right after. The spam was history.

Alrighty, these are the three most important changes I did to the AsUnit framework to make it suit our needs. Well, you have reached the end of my little trilogy. Don’t worry, I still have stuff to talk about.
So see you next time and happy coding!

Popularity: 13% [?]

Tags: as3, asunit, unittests

This entry was posted on Thursday, January 8th, 2009 at 6:47 pm and is filed under Methodology, Programming, Tips. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.