Stas Bekman wrote:
Geoffrey Young wrote:
Now these tests suites won't be normally run by users ('make test'), but could be invoked via 'make alltests' or alike if they want to
I'd be for moving the incomplete ones in there as well (such as push_handlers), thus giving make alltests a broader meaning: run the non-standard tests, even the ones that are in progress. that gives developers a nice testbed for working out issues that doesn't clutter the real test suite with a bunch of skips/failures.
You mean you want to use that as a test bench and moving the tests into the main suite when they are ready? I haven't thought of that. The problem with doing that is losing the cvs history when moving the file back into the main suite.
not really. you remove the old one and add the new one, but the old one always has the history with it. if we can add to the log that the test started out in the testbed directory when we move it, all the history is there.
However you are right, besides losing the cvs history it'd be really useful for us to have this "feature". e.g. I have a test that fails on win32 and I won't commit it to the main test suite and it just keeps on hanging uncommitted.
Re: push_handlers, that particular test doesn't fall into that category. this test is under construction because of a problem in the code, not in the test. The test itself is just fine.
that describes exactly what I had in mind. for instance, I have a few tests for subrequests in filters. I'd like a place for them so that I (as well as others) can work on the implementation. after all, you're supposed to code your tests before you implement, so having a place for tests that exhibit the proper behavior around for all to see is a good idea.
so, push_handlers would fall into that category - implementation incomplete, so it's not part of the standard test suite, but we know what the behavior _should_ look like when it's done. I think the main test suite should only skip tests when external (Foo.pm) or internal-configurable (mpm, threads) dependencies are not met.
Also remember that we skip some tests when building the dist, which includes all under construction tests, so end users who aren't working with cvs, never see them.
So what is your favorite choice for the new directory name?
t_opt? (as in t/ but optional) - the drawback is that now the file completion for t/ won't now work nicely, so I'd rather go with opt_t/
I'd be in favor of just opt, or maybe dev or in_process - the t_ is redundant :)
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
