Design a test fixture

1. Create fixture script, inheriting from TestCase
2. Add properties for each known object in the fixture
3. Override setUp to initialize the properties

AppleScript lack introspection, so registering of fixture is done by using factory methods during compile time. Instead of inheriting from TestCase directly, call makeFixture(), which register the fixture and return a TestCase script object.

In the example, the test fixture is two lists, one empty and one with elements. First create a script object, then add properties for the objects we need to reference later:

script |accessing list|
    property parent : makeFixture(me)
    property empty : missing value
    property notEmpty : missing value

Then override setUp to create the objects for the fixture:

on setUp()
    set empty to {}
    set notEmpty to {"foo", 1}
end

How do you represent a single unit of testing?

Each test of the fixture is represented by a script object in the fixture. Test scripts uses the fixture setUp and tearDown handlers to make sure different tests do not interfere with each other.

Represent a predictable reaction of a fixture as a script object

1. Add a script object inheriting from the fixture
2. Stimulate the fixture in the test() method

Again, you don't inherit directly from the fixture, but call makeTestCase(), which register the test case in the test suite, and return the current fixture.

We can predict that adding "bar" to an empty list will result in "bar" being in the list. Add a script object to the fixture, and stimulate the fixture in its run handler:

script |add item|
    property parent : makeTestCase(me)
    set end of empty to "bar"
    ...
end

Once you have stimulate the fixture, you need to add a Check to make sure your prediction came true.

How do you test for expected results?

If you’re testing interactively, you check for expected results directly in the results or event log pane. You want a way to programmatically look for problems. One way to accomplish this is to use the standard error handling mechanism with testing logic to signal errors:

if empty does not contain "bar" then error "where is bar?!"

When you’re testing, you’d like to distinguish between errors you are checking for, like getting six as the sum of two and three, and errors you didn’t anticipate, like subscripts being out of bounds or messages not being understood.

When a catastrophic error occurs, the framework stops running the test case, records the error, and runs the next test case. Since each test case has its own fixture, the error in the previous case will not affect the next.

The testing framework makes checking for expected values simple by providing a method, "should()", that takes an expression as first argument, and an error message as second argument. If the expression evaluates to true, everything is fine. Otherwise, the test case stops running, the failure is recorded with the error message, and the next test case runs.

Check by calling should() with an expression

In the example, after stimulating the fixture by adding "bar" to an empty list, we want to check and make sure it's in there:

script |add item|
    property parent : makeTestCase(me)
    set end of empty to "bar"
    should(empty contains "bar", "no bar?!")
end

There is a variant on should(). shouldnt() causes the test case to fail if the expression argument evaluates to true. It is there so you don’t have to use "not (...)".

Once you have a test case, you can run it. Send test() to the script object:

|accessing list|'s |add item|'s test()

If it runs to completion, the test worked. If you get an error, something went wrong. The result of sending test() to a TestCase is a TestResult object.

How do you run lots of tests?

Soon you will have many test cases, and fixtures. You could just string together a bunch of expressions to run test cases. However, when you then wanted to run "this bunch of cases and that bunch of cases" you’d be stuck.

The testing framework provides an object to represent "a bunch of tests", TestSuite. A TestSuite runs a collection of test cases and reports their results all at once. TestSuites can also contain other TestSuites, so you can put Joe’s tests and Tammy’s tests together by creating a higher level suite.

Combine test cases into a test suite

Tests are automatically collected in each script file. To make this happen, you must create a property named suite and initialize it with a TestSuite in each ASUnit test script. As usual, you use a factory function for that.

Add this code at the start of your test script using a descriptive name for the test suite:

property suite : makeTestSuite("Test Suite Name")

To run all the tests in the the current file, tell suite to test:

set results to suite's test()

The result of sending "test" to a TestSuite is a TestResult object. It records all the test cases including their failures or errors, and the time at which the suite was run.