If you grep CPAN you'll find a lot of ad-hoc ways of asking usespace if
network testing is permitted.
http://grep.cpan.me/?q=%28if|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 mak
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
On 12 June 2014 02:29, David Golden wrote:
> 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 test
On Wed, Jun 11, 2014 at 11:52 AM, Kent Fredric 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 i
Am 11.06.2014 um 19:08 schrieb David Golden :
> On Wed, Jun 11, 2014 at 11:52 AM, Kent Fredric 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 respo
On Wed, Jun 11, 2014 at 1:37 PM, Jens Rehsack wrote:
> 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 all
Am 11.06.2014 um 19:48 schrieb David Golden :
> [...]
> I still think it's better for tests to check rather than rely on
> testers to set such variables.
You never know whether a test fails because of failure or insufficient
capabilities. So a restricting envvar isn't worse at all.
Cheers
--
J
On 12 June 2014 05:58, Jens Rehsack 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 net
Am 11.06.2014 um 20:24 schrieb Kent Fredric :
>
> On 12 June 2014 05:58, Jens Rehsack 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_NE
On 12 June 2014 06:37, Jens Rehsack wrote:
> > 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!
>
> In that case I suggest to
10 matches
Mail list logo
