Pure Data unit tests

This page presents [unit-test-frame~]. It is a Pure Data abstraction helping to create unit tests for signal objects. Unit-test patching is now a matter of minutes, depending on how familiar you are with the objects under test.

These screenshots illustrate a couple of examples. Only the objects in the grey rectangles need to be instantiated for a specific test. They are connected to [unit-test-frame~], which does all the work.

Using a Pd build which is known to work well (the latest release is an obvious choice), a reference .wav file can be written to disk. The file stores 512 samples in 32 bit floating point format. This reference file will be automatically loaded with the test patch as long as they are kept together in a directory.

With the reference file stored, the same object can now be tested after some change in the code, or a change in the way it is compiled. I use the tests to check what happens if Pd is compiled with all floats in double precision (see http://www.katjaas.nl/doubleprecision/doubleprecision.html). Below is an example of an object which apparently does not work in double precision, [cyclone/bitand~]. The test abstraction computes the differences between reference and signal under test, and also the standard deviation. In this case it is not so spectacular, because the object output has plain zero's.

In the process of fixing the bug, it is very helpful to have the test patch as a monitor. A few lines of C code are quickly written, while testing can be very time-consuming if there is no systematical way to do it. With the [unit-test-frame~] abstraction, testing time can be reduced to the minimum.

For testing of control objects a similar abstraction is available, named [unit-test-frame]. For convenience, it produces an index series 0 - 511 which can be used to generate an output series from the object under test.

automated unit testing

When a bug is fixed, the use of a test patch has not come to an end. Since [unit-test-frame~] performs a test automatically when the patch is loaded, a bunch of unit tests can be run using a script. The standard deviation is sent to the Pd window via [print], and to stdout via [stdout]. The values are tagged with STDDEV-ZERO, STDDEV-SMALL (for deviations not larger than 1e-05) or STDDEV-LARGE. This way, it is easy to track down disfunctional objects from a test log. Ideally, you could have such tests for all classes and run them on the Pd-extended nightly builds. The binary code would then be constantly monitored, and you need not wait for unfortunate users to report issues. Even if you do not rewrite code, there may be changes in the binary builds. For example, when a compiler is upgraded, or a dependency has changed.