Since the perl6 compiler on Parrot is moving ahead nicely in
its new incarnation, it's time for us to start looking at the
official test suite again. As a reminder, Pugs is considered
the repository for the "official test suite" at the moment
( http://svn.pugscode.org/pugs/t/ ).
Having looked at the test suite at various times in the past,
I know that I've often found it difficult to determine where
a given test would/should be located. So, I'd like to start
reorganizing the suite to hopefully make it easier to locate
existing tests and to know where to add new ones.
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
...
03-basic/ basic operators and precedence
03-junctive/ junctive operators
03-comparison/ comparison operators
03-range/ range operators
03-smartmatch/ smartmatch tests
03-meta/ meta operators
03-declarators/ my, our, etc.
...
04-conditional/ if, unless, elsif, etc.
04-loop/ while, until, repeat, for
04-switch/ given, when
04-exceptions/ try, CATCH, exception types, die
...etc...
I'm thinking of this organization scheme as primarily a guiding
principle and not something to be strictly applied. For example,
I wouldn't advocate a strict one-to-one correspondence between
subdirectories and major headings, and I don't think we need to
create directories that end up containing only a single test file.
I.e., each chapter could have a XX-other directory to catch
items that don't fit into another top-level directory, such as
02-misc/, 03-misc/, etc.
Also, I'd consider it okay (but hopefully rare) to create
subdirectories within a major section if there are enough
tests that need to be organized that way.
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.
Thanks!
Pm
