On Dec 23, 2007, at 3:53 AM, IOhannes m zmoelnig wrote:
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".
In a binary system, anything that doesn't success would be a
failure. I don't quite get the WAIT state. Do you have an example
of where to use that?
Any thoughts on how to set up your regression system for use
throughout Pd?
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra