Re: RFC Consensus on Network testing ENV?
Kent,
I'm not sold on this.
The existing author/release/automated test environment variables
define categories of tests that testers opt into.
What you're describing is a variable to detect a capability. It's
closer to NONINTERACTIVE_TESTING, but note which way the defaults go
-- the assumption is that interactivity *is* available unless told
otherwise.
And the reason for the variable in the first place is that prompting
can hang. Avoiding hangs is a higher priority for me than avoiding
failure.
I'd be more interested in seeing a standard way to probe the
capability rather than rely on testers to declare capabilities.
use Test::RequiresInternet; # or skip_all
Or, if particular hosts/ports need to be reachable:
use Test::RequiresInternet { www.google.com = 80 };
David
--
David Golden x...@xdg.me Twitter/IRC: @xdg
Re: RFC Consensus on Network testing ENV?
On Wed, Jun 11, 2014 at 11:52 AM, Kent Fredric kentfred...@gmail.com wrote: Has the user in question granted permission to use the internet. I disagree with the premise that one needs to ask. Users are already running arbitrary Perl code and must take responsibility for anything that it might do and not run it if it does something they don't want it to do. The only thing that interests me is avoiding hassling people with failures in cases that have no possibility of success, e.g. connecting to a host on the Internet when the Internet is fire-walled. That's a question of capability, not permission. David
Re: RFC Consensus on Network testing ENV?
Am 11.06.2014 um 19:08 schrieb David Golden x...@xdg.me: On Wed, Jun 11, 2014 at 11:52 AM, Kent Fredric kentfred...@gmail.com wrote: Has the user in question granted permission to use the internet. I disagree with the premise that one needs to ask. Users are already running arbitrary Perl code and must take responsibility for anything that it might do and not run it if it does something they don't want it to do. The only thing that interests me is avoiding hassling people with failures in cases that have no possibility of success, e.g. connecting to a host on the Internet when the Internet is fire-walled. That's a question of capability, not permission. I think there're setups where smoke tests run in a private. not routed network segment. While this is uncommon, probably an envvar is the right approach, but it should be one like LOCALTESTS_ONLY instead of NETWORK_IS_AVAILABLE. This allows smokers to disable unwanted network tests. How does that sound? (Maybe I don't understand the concern correctly) Cheers -- Jens Rehsack rehs...@gmail.com
Re: RFC Consensus on Network testing ENV?
On 12 June 2014 05:58, Jens Rehsack rehs...@gmail.com wrote: You never know whether a test fails because of failure or insufficient capabilities. So a restricting envvar isn't worse at all. I think he was more saying that he'd prefer: set NO_NETWORK_TESTING=1 over set NETWORK_TESTING=1 Where network testing should run by default and users on boxes where it *couldnt* work ( for whatever reason ) could disable it. That would be more helpful on an imaginary example environment that was sandboxed where calling network functions during 'make test' triggers a SIGKILL or something. And then with that proviso agreed upon, have a module that ascertains ( using basic testing within the test itself ) if network behaviour is conducive to making the test pass, and if so, permit the test to run ( guarding the test against actual network problems instead of relying on an ENV guard , and using the ENV guard only for users who have continued issues with the heuristic failing to fail properly ) 1. begin test 2. load test networking module module 3. is NO_NETWORK_TESTING? SKIP! 4. can access specified resources? yes - run tests no - SKIP! -- Kent
