Re^2: IO::Interface and System-dependent Testing

Interesting response. I have no idea what led you to the conclusion that the code performs session management..

I'm not too worried that the code relies on layer 2 or layer 3 information, that much is a given for the nature of the work the code is doing. What concerns me is that on linux I may need to know eth0 is 'external' and eth1 'internal', where on BSD these may be combinations of en, xl, or fxp. The actual name of the interface is secondary; it's the IP and netmask that are more important.

Likewise, the detection of the interfaces is secondary; I just need to have something on which to base other higher-level tests, which needs to be valid for the system under scrutiny.

As I said I can use IO::Interface to verify that my code is doing the right thing (my module just extends IO::Interface), so in this particular instance, the problem is solved.

The bigger question is how to provide some level of system independence while interrogating the system for information (whether it's network interfaces, ARP table entries, or the partition table of a drive), and have this done in an automated manner so non-technical QA staff can run unit tests as part of their code verification.

I realise the target is somewhat vague, but shurely shomeone shomewhere has run into this before.

Comment on Re^2: IO::Interface and System-dependent Testing

Replies are listed 'Best First'.
Re^3: IO::Interface and System-dependent Testing by starbolin (Hermit) on Apr 21, 2005 at 06:03 UTC
moot writes: I have no idea what led you to the conclusion that the code performs session management. this, from OP: ,,,bunch of code that needs to determine currently available network interfaces moot writes: The actual name of the interface is secondary; it's the IP and netmask that are more important. And each is a different level of abstration, a different level of complexity. The deaper you go into the the layers the more information you have to provide and the less isolation you have from the enviroment. The distictions between layers are not "secondary"; they are the core of the problem. To rephrase my original post. If we're testing a database application we provide an artificial dataset for an environment. Why wouldn't we provide an artificial environment for a network applicaiton? I'm sorry I misunderstood your OP and I know I'm not addressing your core issue of automation but please don't shoot the messenger. As you said yourself:"the target is somewhat vague". s//----->\t/;$~="JAPH";s//\r<$~~/;{s\|~$~-\|-~$~\|\|\|s \|-$~~\|$~~-\|\|\|s,<$~~,<~$~,,s,~$~>,$~~>,, $\|=1,select$,,$,,$,,1e-1;print;redo}	[reply]

Replies are listed 'Best First'.

Re^3: IO::Interface and System-dependent Testing
by starbolin (Hermit) on Apr 21, 2005 at 06:03 UTC

moot writes:

I have no idea what led you to the conclusion that the code performs session management.

,,,bunch of code that needs to determine currently available network interfaces

moot writes:

The actual name of the interface is secondary; it's the IP and netmask that are more important.

To rephrase my original post. If we're testing a database application we provide an artificial dataset for an environment. Why wouldn't we provide an artificial environment for a network applicaiton?

I'm sorry I misunderstood your OP and I know I'm not addressing your core issue of automation but please don't shoot the messenger. As you said yourself:"the target is somewhat vague".

s//----->\t/;$~="JAPH";s//\r<$~~/;{s|~$~-|-~$~|||s |-$~~|$~~-|||s,<$~~,<~$~,,s,~$~>,$~~>,, $|=1,select$,,$,,$,,1e-1;print;redo}

[reply]