On Tue, 10 Jul 2001, Geoffrey Young wrote:
> > Also how about specifying the order in the Makefile.PL? I think Brian
> > Moseley has asked for the same a few weeks ago and ended up using the
> > Makefile.PL, see the earlier thread about ordering.
>
> duh, don't know how I forgot about that - 'tis already been discussed :) my
> brain is mush.
:)
> > Of course we can implement anything we need, but first I'm trying to
> > understand the need ;)
> >
>
> it wasn't a need, really, but a preference - not the type of thing brian was
> talking about.
>
> even though all the tests are always run I thought it made sense to proceed
> with them in a logical order, making them more informational. first load
> module, them run a plain test, then run a complex test, etc...
>
> for instance, I came up with the idea of checking for a sucessful filter via
>
> my $content = ok GET_BODY '/handler';
> ok ((GET_BODY '/filter'), "$content$content");
>
> now, GET_BODY returns the body, regardless of error, while the next test
> does not suceed unless the first is 200. thus the aggregate result is 1 ok,
> 2 not ok when really both tests failed.
may be the test logic is flawn? How about checking the returned data and
ok() on it instead of just checking true/false? I suppose I miss
something...
> I could use GET_OK before that, but what I'd like to do is GET_OK '/handler'
> in its own test as to not repeat stuff. whether this test fails before or
> after the filter test makes no difference, except that I think it makes more
> sense to know the filter test is going to fail based on the fact that we
> couldn't even get a plain test right...
IMHO the tests should work in this way:
- tests either pass or fail, if they fail you have a problem, no matter
the order of execution or else (well in most cases. sometimes apps like
LWP are too big and it's fine to have some tests failed and still use a
subset of the features without any problem). but we want to strive for
cleanly passed make test, right :)
- now when the tests fail you want to run the test in the verbose mode,
and that's when all those debug prints come to rescue, the better the
debug prints are the easier is to debug the test. Remember that debugging
prints under Test::Harness are nice, you don't have to disable them, since
they don't appear in the non-verbose mode.
- as you have seen recently I've added --order=random mode whose purpose
is the opposite: run the tests in the random order so you can reveal bugs
which won't be seen otherwise when the test happen in the same order and
seem to do the right thing. So I believe the right test writing approach
is to have independent tests and if you need to stuff 100 tests in one
file because they are all dependant, let be it. You can split the tests
into a few files but call them all from one file if you like.
> as I said, just a preference, definitely not a need for me. maybe for
> others, though...
true :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
