# from Michael G Schwern
# on Wednesday 11 April 2012 11:06:
>> What exactly makes you uneasy? Maybe there is a way to address that
>> if you can be more specific.
>
>Mostly that it's cramming yet more complexity into core test library
> for a fairly narrow use case and functionality that lives quite
> happily in its own module. It's already difficult enough to keep
> stable.
>
>To reverse it, why should it be in Test::More? "People don't like to
> have extra test dependencies" is not accepted.
Looking at this a different way, instead of a library, make a distzilla
extension (or whatever) which generates (and regenerates) a 00-load.t
as per Ovid's earlier example.
The trouble with having it in a library is not just that you have a test
dependency, but also that you have to add more complexity to the
library (and then you have a test dependency on a newer version)
whenever someone wants to do a complex thing.
Many modules in a distribution may not load unless $optional_dependency
is satisfied. But, it is good to precheck all of the modules in a
distribution before starting tests (aside: did someone say prefork?)
and helps to wrap this in some useful diagnostic + bail out.
I think something which embeds code in a 00-load.t, plus helps you
maintain a list of modules by scanning lib/ would be a handy way to do
that. (Perhaps a list + hash to address the optional dependencies and
each optional module has a subref to determine if it is enabled.)
One could argue that the functionality should be included in each test
file to keep things orthogonal. Such a one may find that there may be
a way to require("./t/00-load.t") from each test file, but might also
end up with a library and/or a hybrid with regenerative breaking
(prefork.)
--Eric
--
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
