Sean O'Rourke wrote:
I agree with that. take the example of reverse (array) in this thread.Hm. I'm not sure how well it goes with the Perl philosophy ("the perldocumentation, not code. An obvious question is how to extend it to be a more thorough test, whilst not spoiling the documentation. We'd want to intersperse text with the test-code; and probably mark a few bits as "hidden", from a normal documentation view (levels of hiding might be defined for overview vs. reference vs. guru levels of understanding).
language is what the perl interpreter accepts"), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I don't think real tests, which exercise specific corner cases,
mix very well with user-level documentation of any sort.
Really, the testing should have a number of other tests to be complete,
including thorough testing of boundary conditions.
e.g. - tests of reverse on
0. undef
1. Empty list
2. (0..Inf) - Error ?
3. Mixed data types
4. Complex data types
5. Big (long) lists
6. Big (individual items) lists
7. Array References
8. Things that should raise a compile-time error
9. Things that should raise a run-time error
This gets pretty boring in main documentation.
Writing a complete test suite really also needs reasonable knowledge
of how the internals are written in order to understand the kinds of
tests that are likely to provoke errors. (More thoughts on this if requested).
A related issue is that test ordering should relate to implementation.
E.g. if reverse is implemented as "copy to a new array and then do in
place reverse", then "copy to a new array" should be tested first.
R.
