Its looking really good, hope the bug doesn't drive you nuts. The only thing I object to is the -utest.pd name. Perhaps I have a really bad memory, but I never remember what stuff like that means. That why I am a big fan of using full words. Typing really doesn't take very long, but if you can't remember what particular abbreviation to use, it can be maddening. How about -unittest.pd?
.hc
On Oct 26, 2011, at 1:29 PM, katja wrote:
Hello,
Here is a .zip with an improved method for unit-testing of signal objects. Instead of a template, there is now an abstraction 'unit-test-frame~.pd' handling the tests. The input of that abstraction consists of:
- name of the reference file (32 bit float .wav file, like Roman
suggested)
- signal (or system) under test
- optional delay between test-trigger and test-snapshot (for filters
etc.)
The reference file can simply be created from within the unit test patch (running in a 'good' Pd), and must be kept with the test and the abstraction in a directory. The abstraction compares signal under test with reference, computes standard deviation, and sends a tagged result to Pd window and stdout:
STDDEV-ZERO 0 reference: <reference> (when stddev = 0) STDDEV-SMALL <stddev> reference: <reference> (when 0 < stddev < 1e+05) STDDEV-LARGE <stddev> reference: <reference> (when stddev >= 1e+05)
The tags facilitate grepping different categories of 'errors' from a test log. Note that a small stddev may sometimes indicate improved accuracy in an object! Like when Pd-double is tested against current Pd.
By the way I did not find a way to set samplerate for a test. I definitely do not want the test patch to mess up other audio settings, like number of channels. Therefore an audio-dialog message to pd is not an option. However there's an inlet reserved on unit-test-frame~.pd for possible future solution of this issue. From a remark by Roman Haefeli in another thread, http://lists.puredata.info/pipermail/pd-dev/2011-10/017694.html, I learnt that -noaudio may be a useful option for automated signal object testing.
Please report if you have comments on the proposed test stuff. I should mention a hidden agenda behind the efforts: the intention is to produce dozends or even hundreds of unit-tests in short time, and use these for testing Pd-double. Then we could finally make some systematic progress in that field. Apart from that, the tests could be useful for rewrites/refactorings in general, and for tracking down optimizer-troubles.
Katja
. <unit-tests.zip>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams