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?
well, assuming we're all not working in a vacuum (which we are currently :) having tests available for incomplete features means that anybody can activate the tests and know exactly what we want from the (missing) featureset. so, theoretically you could commit some tests and somebody else could use them to hack away at the functionality you have in mind. seeing as how you're already overworked and all :)
Hmm, aren't we inventing this problem? I can't quite see people coming out of the woods and offering help. I think this is just looking for a trouble. However if you think it's useful go ahead and add one. see more on this below.
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?
I'd like to see it in t/ someplace - if t/response and some of the other t/ directories can be special, I'd think we could also make t/opt (differently) special as well, no?
Not quite so. I want to be able to specify new t/conf for each optional test which one of the main reasons why I suggested that. Adding tests under t/ you may affect other tests when you change the config.
> 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.
ah, yes. opt specifies optional, and the ones you are talking about really are not optional, are they, in the sense that if they fail it's ok. I'd rather see 'extended' or something like that - something that indicates additional tests that shouldn't fail (and it's problematic if they do).
Good thinking.
So we can have modperl-2.0/extra_t/ for what I want and modperl-2.0/dev_t/ for what you want. I still insist on having some way to indicate that these are test dirs. Though since I want tests in extra_t being independent from each other, it'll include a whole set of tests dirs, like so:
modperl-2.0/extra_t/foo/t/conf/ modperl-2.0/extra_t/foo/t/response modperl-2.0/extra_t/foo/t/TEST modperl-2.0/extra_t/foo/t/SMOKE modperl-2.0/extra_t/bar/t/conf/ modperl-2.0/extra_t/bar/t/response modperl-2.0/extra_t/bar/t/TEST modperl-2.0/extra_t/bar/t/SMOKE
TEST and SMOKE can be completely autogenerated so we can keep the amount of committed files to a minimum. So now I can do:
cd modperl-2.0/extra_t/bar/ && t/TEST
or even have modperl-2.0/extra_t/bar/Makefile.PL so we will get 'make test' working as well. Think of these as small sub-projects with no lib/xs files of their own, just the test suites.
Now I believe that the same principal should apply to modperl-2.0/dev_t/, so we don't step on each other toes.
__________________________________________________________________ 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]
