On Dec 20, 2007 9:27 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> There are certainly plenty of organization schemes we could use
> for this, but one that leaps to my mind is to organize tests based
> loosely on where the feature is described in the synopses or the
> camel book (the p5 camel book for now, the p6 camel book when it
> comes out). So, if we named subdirectories of t/ with the
> synopsis number and major subsection name, we could end up with
> something like (names here are just for illustration at the moment):
>
> t/
> 01-sanity/ tests for basic sanity items
> 01-test/ tests for the Test.pm harness
> ...
> 02-comments/ whitespace and comments
> 02-datatypes/ built-in data types
> 02-variables/ variables
> 02-names/ names and scopes
> 02-literals/ literals
> ...
>
this is on the right track, but still a bit confusing to me. many
tests for cpan modules use a similar structure, but it often implies
test directory execution order. this is not what you mean by the
directory naming convention you've chosen.
also, as it is, this scheme leaves no room for ordered test
directories at a later date. i can't think of a use for them in this
instance off the top of my head, but people smarter than me might find
one eventually.
here's my suggestions, based on your structure
t/
spec/
S02-comments/
S02-misc/ # or -other
this gives us a nice tidy location for all spec tests, and helps
clarify that the directory naming isn't meant to imply test execution
ordering (although there are few forward references in the synopses by
design, few != none.)
it also gives us room for additional directories, for example
t/compilers/perl6/00-parrot/, t/compilers/kp6/, t/misc/, and as i said
previously, t/01-sanity/ etc.)
> Any thoughts (positive/negative) about this approach? Unless
> there are major objections I will probably start looking into
> reorganizing some of the basic tests in the suite along these
> principles.
>
great idea! i'd love to help. as a start, we can create or use a
utility (like 'ack') to hunt for smartlinks in the existing test files
and move the test files to whatever structure we've agreed upon. that
should address the first 80%. then manual review can be done at the
file level to do the second 80%. the last 80% is the hardest:
reorganizing the subtests within and between the files.
however it gets done, i think it'll help all the perl 6 contributors
immensely. it'll certainly help me find the test files i need to run
in order to implement new bits of perl6.
~jerry
