Chromatic wrote:
I agree that CVS makes it difficult to change things later (I assume you don't want to risk Subversion in its current state). However, I would suggest that you hold off creating the elaborate structure until we need it. Bucket loads of empty subdirectories benefit no one. And CVS has no problem adding things later.I'm prepared to start checking in Perl 6 tests on behalf of the Perl 6 documentation folks. These should be considered functional tests -- they are exploring the behavior we expect from Perl 6. Anything that's not yet implemented will be marked as a TODO test, and we'll figure out a way to extract the unimplemented features so people will have small tasks to accomplish.Brent Dax had a nice suggestion for Perl 6 test organization. I like it tremendously. I repost it here to solicit comments -- to make this work, I'll need to change the Perl 6 test harness to find all of the tests. I'll also need to create several different subdirectories as appropriate. Rearranging things after the fact is a bit of a chore with CVS (if you want to keep revision history), so I welcome feedback. Brent's post follows.[...]
Currently we are concentrating on the literals: we should be able to do most of those tests in 3-4 files (I still hope to persuade people to use a table-driven approach for these tests): so no subdirs are necessary. Also, I have a preference for flatter structures than that proposed. It is fair to assume that there are multiple classifications possible for any test: a deep structure tends to force unnecessary specialisation, and commitment to one particular viewpoint.
Could you elaborate on you need to change the test harness to "find all of the tests": are you proposing something more complex than "find all *.t files (recursively)"?
Dave.
