network testing is permitted.
It seems wide spread enough that we may as well establish a common way of
doing it, document it, and then enhance the available tooling to make it
That way, instead of a user having to see a notice in their test output and
manually change ENV to suit ( and have to do this many different ways for
many different packages ), they'll just have to set the relevant option in
their installation stack.
And this would be a standard option for those running smoke testers, and
smoke testers who felt that network testing was something that *should*
work on their boxes could set the relevant configuration tunable, and we'll
get better CPAN testers coverage as a result.
Once we decide on an "official" and "blessed" ENV key, we can go about
getting support for it added in various testing tools, like:
That way, Test authors only need to do:
use Test::Is 'networked' ;
Or similar instead of having to hand code a bunch of ENV conditions and
Though the exact syntax those modules should use can be decided at a later
date and we should simply decide on the ENV name to use.
Some tools have their distribution name prefixed in their ENV key, which
may be because those distributions consider network testing a bad idea,
even if it is otherwise indicated globally as ok, and requesting *explicit*
indication for itself to run. At least, that is why I imagine it is done.
It may just be out of paranoia of ENV key clutter causing unintentional
keys to be in scope and have people running tests without meaning to.
Technically we don't really need to solve this as a feature within the ENV
key, I hashed together something way more complicated that would allow
per-distribution granularity settings without any specific
testing/toolchain infrastructure, but it seems its not really necessary.
Ultimately if a smoke tester wanted that degree of granularity, the table
of rules could be established in the smoke testing toolchain itself, and
per-package ENV flags could be set up to allow network tests for some dists
and not for other dists using this simple approach.
I also considered using values other than "1" in this ENV flag( ie:
"Dist-Foo:Dist-Bar:Dist-Baz", but it all smells too much of featureitis and
things we don't need yet and overcomplicates things.
Essentially, the simplest thing that could work is just
This is informally used in a place or two already, mimics our existing set
of ENV vars, and its sensible enough that we may as well standardize on it.
- A few places use NETWORK_TEST (singular)
( WWW::Offliberty, LBMA::Statistics , Net::Douban
- A few places use NETWORK_TESTS (plural)
( RDF::RDFa::Template }
- Quite a few places use SOMEPREFIX_NETWORK_TEST or SOMEPREFIX_NETWORK_TESTS
( Net::Social::Mapper, WorePAN, RDF::Query, RDF::Trine, Data::Feed )
- RUN_NETWORK_TESTS is seen in at least one place
( IO::Pipeley )
- Other Weird things exist:
- TEST_YAR_NET_CONNECT in Net::YAR
- AUTHOR_TEST_NET_ROUTE in Net::Route
- HAS_INTERNET in WWW::OPG
- TEST_INTERNET in WebService::CIA
- PUGS_TEST_ALLOW_NETWORK in Perl6::Pugs
- TEST_NET in MojoX::UserAgent
- ONLINETESTS in HTTP::LoadGen
- USE_NETWORK in Arch
Well, you get the picture. Its a complete mess.
I merely got bored with enumerating all the ways network testing could be
enabled, and I doubt anyone running a smoker would care enough to track
them all down like I just started to.
Better to say "If you want network tests to be smoke tested, USE THIS"
( ~KENTNL )