Mathieu Bouchard wrote: > On Sat, 22 Dec 2007, IOhannes m zmoelnig wrote: > >> - keep the tests as simple as possible, but not simpler >> one should be able to write a test fairly easily; i think shortcuts are >> most likely not needed most of the times (e.g. iirc, matju introduced >> several shortcuts in his unity-test frameworks to test for >> mathematically important concepts (like assosiativity of operations); i >> think it is way simpler to just program 3 tests manually instead) > > I think that the tests for associativity are not going to be so useful, > but they're still a good practice in some way. However, my goal for > PureUnity was not just to make regression tests, but also invent a bunch > of superclasses for all the Pd builtins (and some externals) in order to > make a categorisation of objects that makes sense from the point of view > of how you use the objects: e.g. [timer] and [realtime] would be in the > same category not because they deal with time, but because the left bang > starts and the right bang stops and outputs a float. > >> - allow fail-tests which have to return FAIL-state in order to success > > How do you know that a method has failed properly?
because it returns the expected FAIL-state. the problem is the same as "how do you know that a method has succeeded properly" you need a-priori knowledge about the expected return state of the test. i usually do this by a discrimination based on the test-name. (prefixing "fail") e.g. "fail_blabla" will only success if it returns the state "FAIL" immediately or after a "WAIT". fgamdsr. IOhannes _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list