Test cases (was: for review: big ints)
trd at stimpy.cs.mu.oz.au
Mon Apr 6 14:50:13 AEST 1998
On 06-Apr-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> Finally, some test cases would be a good idea.
> (tests/general/arithmetic.m would be a good thing to start with.)
On adding new test cases:
The tests directory is getting pretty full. It's sometimes difficult
to tell feature tests from regression tests, and lots of the feature
tests are together.
I'd like to add better structure to the tests directory, but it's
a lot of work to do that all in one go, so I think we'll have to
apply the "as you go" approach.
So for these tests cases, I'd suggest a new directory:
because it's just testing a library module.
For language features (which are generally compiler+library+runtime changes),
I don't really see the point of dividing tests on how they are tested,
so eventually I'd prefer not to have `hard_coded' (you can do the same
thing with some make rules). I think the best scheme would be to divide
language features (types, modes, plain old code)
implementation features (pragmas, non-language compile options)
library tests (unit tests, sanity tests, library regression)
build environment (mmake, scripts, dependencies, mdemangle)
programs (full programs, e.g. samples and extras and others)
And then further subdivisions, including regression tests: e.g.
Since it doesn't actually give us any productivity benefits to have
tests arranged in this way (except that I've been asked on several
occasions "where do you think I should put these tests?"),
I don't think we should spend time doing it now, but would be nice
to append to the current hierarchy with as much of this kind of
structure as we can.
Tyson Dowd # So I asked Sarah: what's the serial number on
# your computer? She replied:
trd at cs.mu.oz.au # A-C-2-4-0-V-/-5-0-H-Z
More information about the developers