Steven,

Have posted previous mail on the utplsql board.

>I don't see why you would
>turn tests on and off. The
>whole point (as I understand
>it) is to build a large body
>of unit tests, ALL of which
>must work ALL the time.

I guess I was envisioning real-life things like changes in requirements or state of data for the unit making some tests obsolete or temporarily irrelevant, where you might not want to remove them altogether (the equivalent of commenting out an a call to utassert), or situations where a failed test call to a non-deterministic function may affect the results of following tests.

>The performance of unit
>tests are not relevant.
>Performance of the app is, but
>that is a separate issue.

Could you elaborate - I find this surprising since most tuning books appears to concern
themselves with finding bottlenecks in apps. and often the tuning crusade ends up pointing at a single function (e.g. your battle with the is_number function). If we determine an overall performance criteria at design time, the sub-functions themselves could be reasonably entitled to specific portions of the total available time. My feeling is that a function should be seen to be a failure if is performance is sufficiently poor so as to cause the app. to fail its performance
criteria (this sort of test would have probably prevented the original is_number function from ever being released). I concede that in many cases this would be a difficult thing to quantify. It would be a breeze to assert, however.

>- In terms of reporting on the
>test results, the approach is
>red light-green light. Either
>it works (green light, nothing
>else to report) or fails (red
>light, in which the testing
>mechanism does already report
>on sources of failure.

I agree, but I was really asking whether the testing history was as valid and useful/interesting as the version history.

Padders