Specifies an object to handle logging results as they are generated. This allows you to bypass the default text logging output, in order to store, chart or display the output differently. The logger object must expose 4 methods:

logBegin(name:String,description:String,iterations:uint)
Called when a new test begins.

logError(name:String,details:Error)
Called if an error occurs while testing a method. The details parameter will be null if the method was not found in the test suite, or will error object that was generated if an error occured while running the method.

logMethod(name:String, time:uint, iterations:uint, details:
Called after a method was tested successfully. The time parameter will be passed the total time for all iterations, calculate average with time/iterations. Currently, the the details parameter is only passed a value for "tare" methods - the number of times the tare method was run before returning consistent timing.

logEnd(name:String) Called when a test ends.

Specifies a function to handle the text output from the default logging. You could use this to write the default output to a file, or display it in a text field. For example setting myPerformanceTest.out = trace; will cause the log output to be traced.

Pauses or resumes the performance test queue.

When synchronous is set to false (default) each method is tested in a separate frame to prevent the tests from freezing the UI or timing out. Setting synchronous to true forces tests to run immediately when added, and all within the same frame.

This is a convenience function to allow you to access a single instance of PerformanceTest globally, so that you have a single test queue.

Allows you to test the performance of a single function. Handy for testing functions on the timeline.

This method allows you to test the time it takes to render a complex display object. This is a largely untested feature in this version of PerformanceSuite.

Tests a suite of methods. The suite can be any class instance with public methods. The suite object can optionally expose name, description, and methods properties that will be used if the corresponding parameters are not specified. The suite can also expose a tare method (see below for info).

A test suite should group similar tests together (ex. testing different loop structures), and each test method should run for a significant amount of time (because testing methods that run for only a few ms is unreliable). You can use a loop inside of your test methods to make simple operations run longer.

Similar to unit testing, you can write test suites alongside your main project files, and have the test suite methods call methods in your project to test them. In this way you can create an evolving performance testing framework without having to modify your project source code.

See the samples for more information on writing test suites.

Tare methods
If a test suite exposes a public method called tare, it will be run repeatedly (up to 6 times) at the beginning of the suite until it returns a consistent timing result. That time will then be subtracted from the results of all other tests. This is useful for accounting for "infrastructure costs".

For example, if you have a suite of tests to test mathematical operations, and every test has a loop to repeat the operation 100000 times (to get measureable results), you could write a tare method that contains an empty loop that repeats 100000 times, to eliminate the time required to run the loop from your results.

Runs a test function in synchronous mode and returns false if the average time (accounting for number of iterations) is greater than the specified targetTime. This is useful for developing unit tests for performance. For instance, the following example would fail the unit test if myFunction took longer than 100ms to run on average per iteration:
assertTrue(PerformanceTest.getInstance().unitTestFunction(100, myFunction));

Runs a test render in synchronous mode and returns false if the average time (accounting for number of iterations) is greater than the specified targetTime. This is useful for developing unit tests for performance. For instance, the following example would fail the unit test if mySprite took longer than 100ms to render on average per iteration:
assertTrue(PerformanceTest.getInstance().unitTestRender(100, mySprite));

Runs a test suite in synchronous mode and returns false if the average time (accounting for number of iterations) is greater than the specified targetTime. This is useful for developing unit tests for performance. For instance, the following example would fail the unit test if mySuite took longer than 100ms to run on average per iteration:
assertTrue(PerformanceTest.getInstance().unitTestSuite(100, mySuite));