One of the things that we use quite frequently in application/game/component development is test suites. I’ve never seen anyone post on this before, and since we have been developing a large set of test suites for the gskinner lightweight interface components (screenshots below), I thought I would give them a mention.

The test suites we create are similar to unit tests in that they allow us to test a single element thoroughly in isolation. The big difference is that instead of using a big block of code to test another big block of code, we develop a visual console that exposes most (ideally all) of the class’s public interface. While this approach is less automated than unit testing, it does provide a large number of benefits over unit tests:

1. It provides for more flexible testing – you can play with as many command sequences as you’d like, without modifying code between each test
2. It allows you to test the visual aspect of your class – unit testing is great for testing data handling classes, but it falls short when you need to ensure that performing a certain sequence of tasks on a bound class results in the appropriate visualization of its state
3. In a similar vein, our test suites give us a great place to play with component skins and aesthetic designs. We can tweak the design, run the test suite and immediately see how that design will work in a variety of states.
4. Test Suites are faster to develop. You only have to write a single hook for each public member in your class, rather than writing a test for every i/o possibility for the member. The onus to test each variation rests on the human tester (this lack of automation is also a definite disadvantage).
5. Perhaps most importantly, a well designed test suite can become a deliverable. Hand the test suite off to the client, and it gives them something to play with and show stakeholders while you continue development. This is definitely something you can not do with unit tests.
6. It’s more interesting/rewarding. This is personal opinion, but I like to be able to view what I work on – it’s a big part of the reason I gravitated to Flash. Developing unit tests can be extremely tedious, with little to show at the end except a unit test report. Test suites give you something to play with and show off.

Unit tests definitely have their place. They are particularly good at automating the testing process for large projects, or projects that are likely to undergo a large amount of refactoring. They are also great for testing utility classes, or data centric classes with few/no visual aspects.

The places I’ve found test suites to be most effective are with highly cohesive, encapsulated visual elements and components. We’ve also found them extremely useful for testing/developing server delegate classes, and often use them as a follow-up deliverable to the back-end team after obtaining sign off on a server interaction spec.

Here are a couple of screenshots of test suites we’ve used recently. Click an image to view a larger version.

The first screenshot shows the beginnings of the glic test suites. These will become part of our marketing materials when we release. These are doubly useful for testing, because they are developed using glic – one more opportunity to find bugs.

The second is a screenshot of a test suite for the introNetworks project. Following sign off on the server interaction spec, we developed this simple test suite to allow us to test our server delegate class. When it was completed, we were able to hand it off to the introNetwork’s back-end development team so that they could use it to test their systems. The result – reduced inter-team dependencies, faster deployment and painless client/server integration.

Who else uses these? Do you do it any differently? Comment below.

In semi-related news: We’re pretty close to having a datagrid (among other new components) in glic now too. It’s turning into a pretty sweet set IMHO.