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.
If you view the cvs log it doesn't quite show you the log of what it used to be an now lives in Attick... however I suppose we can live with that.
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.
I like the part:
the main test suite should only skip tests when external (Foo.pm) or internal-configurable (mpm, threads) dependencies are not met.
which we already ensure for the releases.
Though there is one catch: If nobody else but you can run the tests what's the point of committing them? Why committing incomplete tests in first place? How do we know whether the tests in opt_t are supposed to work or not? And therefore trying to report a problem to you just annoying you?
The only reason push_handlers is in the main suite, is because after I committed it I've learned about a problem and therefore disabled it, instead of deleting it. otherwise I would never have committed it in first place.
I think you should keep incomplete tests uncommitted, since they are of no use to others but the developer and just lead to a confusion and wasted time.
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 :)
but it doesn't imply that this is a test dir. Any other ideas?
> maybe dev or in_process
You missed the point of my idea - my proposal is not about having a place to dump under-construction tests, it's about having solid working tests, which for some reason don't fit into the main test suite, please see my original message which includes examples.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
