develooper Front page | perl.cpan.workers | Postings from June 2014

RFC Consensus on Network testing ENV?

Thread Next
Kent Fredric
June 11, 2014 12:56
RFC Consensus on Network testing ENV?
Message ID:
If you grep CPAN you'll find a lot of ad-hoc ways of asking usespace if
network testing is permitted.|unless%29\s.%2BENV.*NET

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
make sense.

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
skip rules.

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.

Other thoughts:

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 }
( 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_INTERNET in WebService::CIA
  - TEST_NET in MojoX::UserAgent
  - 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"


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About