Andy Lester wrote:
>> yeah, well, you could say that. last time I installed my washer I said
>> "looks pretty level to me, but I know where my level is if it makes a
>> racket"
>
>
> That's fine, but I'm still not shipping my washing machines without
> explicit instructions to level the damn thing. Similarly, I'm not
> making any of my tests optional except in the case of tests where they
> don't affect direction operation, as in t/pod{,-coverage}.t.
well, it's nice that you have that luxury with the code you write, but not
every module requires or can live with that kind of behavior :)
consider something real like mod_perl. some of our tests are optional and
are skipped in various circumstances. why? well, not every installation
has LWP, so we skip some tests where we require it when all it does is make
our test writing life easier. not every apache installation has mod_auth
installed, so we skip tests that exercise mod_auth-behaviors. I could go
on, of course, but you get the idea.
the same analogy can hold to various perl modules, where one class interacts
with something that not everyone cares about. say you've got some module
with shared code, client-specific code, and server-specific code. say some
user of that code only cares about the client part. now say that testing
the server code requires 3 additional Test:: modules. you're going to force
the user to install those modules and run those tests even though they will
be exercising code he doesn't care about? I don't think that kind of thing
makes sense at all. furthermore, I think that doing so gives rise to
conversations like the one that started this thread, where people see umteen
test dependencies and get frustrated.
remember, we're in an uphill battle here in the testing world. every time
we frustrate a user we make it harder on ourselves - too many up-front
dependencies and folks will skip the tests altogether and carry that
frustration back to their desk when they decide whether to write tests
themselves...
--Geoff
