Using MonsterDebugger with AsUnit tests

So I've been using two new tools lately to develop my framework - De Monster Debugger and AsUnit. De Monster is a tool that allows for introspection of you running swf through their air front end. All methods and properties are exposed, and can be executed or edited right from their tree interface. You can find it here or watch Lee Brimelow's tutorial about it.

AsUnit is a unit testing framework for actionscript which allows you to run automated test suites on the smallest, indivisible pieces of your code to ensure integrity. In my opinion the real power of unit testing comes from two places - it formalizes the elimination of possible bug causes, (no more sloppy, randomly placed traces or commenting out code), and secondly it's no big deal to run your entire suite of tests every time you compile your swf, so you catch on when bugs in one class effect other classes in ways you didn't expect.

In essence, AsUnit is basically a framework for setting your classes and pieces of code on stilts for further examination, but to achieve this, it's standard practice to encapsulate your classes into the test suites in awkward - yet beneficial (to the unit testing) - ways. Let's examine these.

package com.framework.tests.units {

import asunit.framework.TestSuite;
import com.framework.tests.units.LinkNodeTest;
import com.framework.tests.units.LinkedListTest;

/**
* @author Will Saunders
*
* Unit Test Suite for the framework
*
*/

public class AllTests extends TestSuite {

public function AllTests() {

super();

// Link Node Tests
addTest(new LinkNodeTest("testInstantiated"));
addTest(new LinkNodeTest("testAutoAddChild"));
addTest(new LinkNodeTest("testManualAddChild"));
addTest(new LinkNodeTest("testRemoveChild"));

This is an example TestSuite for AsUnit. Test classes - LinkNodeTest in this case - contain the logic for administering and checking the tests, while TestSuites group all the tests together. If you look closely, however, you'll notice that each of these tests happen independently of one another - one test does not run on the same data objects as the ones before or after because a new instance of LinkNodeTest is established for each test. Furthermore their syntax abstracts the inner parts of the Test classes from us. While this method is mostly always a good thing (for the sake of maintaining granular, "blank slate starts" in the tests), but if you want to look into the tests with Monster Debugger to see what's actually happening or what the data looks like after your tests have run you'll have to jump through a few hoops.

First we will add a lasting reference to the particular instance we'd like to examine more closely. I only set aside one of these at a time and to encourage myself not to get too far away from the point of unit testing. We will also add the necessary classes for the debugger: 

package com.framework.tests.units {

import asunit.framework.TestSuite;
import com.framework.tests.units.LinkNodeTest;
import com.framework.tests.units.LinkedListTest;

import nl.demonsters.debugger.MonsterDebugger;

/**
* @author Will Saunders
*
* Unit Test Suite for the framework
*
*/

public class AllTests extends TestSuite {

public var failedTest:LinkedListTest = new LinkedListTest("testRemoveChild");
public var bugger:MonsterDebugger = new MonsterDebugger( this );

public function AllTests() {

super();

// Link Node Tests
addTest(new LinkNodeTest("testInstantiated"));
addTest(new LinkNodeTest("testAutoAddChild"));
addTest(new LinkNodeTest("testManualAddChild"));
addTest( failedTest );

Now through this reference to the test, we may inspect the inner contents. In the following picture you can see the failedTest reference and the data inside of it :) -