Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config
On Mon, Oct 22, 2001 at 02:08:05PM -0600, chromatic wrote: So if a test depends on a module in the core it should check that the module is avaliable, so that the test is skipped with older perl releases. But this is a little funny. How are these new tests going to wind up on old perl and libnet versions? I understood that as Graham being unsure about using Test::More in the tests. Oh, we can fix that. Just distribute Test::More with libnet, a la CGI.pm. I'll just go summon my Army of Test::More Octopi to assimilate libnet. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One no paste enema lycos is taught about it my ass is sealed -- Schwern
Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config
On Mon, Oct 22, 2001 at 01:44:32PM +0100, Graham Barr wrote: Any patches to modules from libnet, and test additions, should be against the latest libnet on CPAN, I do not want the core to diverge. I can understand this. We should be patching the CPAN libnet. So if a test depends on a module in the core it should check that the module is avaliable, so that the test is skipped with older perl releases. But this is a little funny. How are these new tests going to wind up on old perl and libnet versions? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One I'm not actually Kevin Lenzo, but I play him on TV.
Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config
On Mon, Oct 22, 2001 at 02:08:05PM -0600, chromatic wrote: On Monday 22 October 2001 14:10, Michael G Schwern wrote: I can understand this. We should be patching the CPAN libnet. In progress. So if a test depends on a module in the core it should check that the module is avaliable, so that the test is skipped with older perl releases. But this is a little funny. How are these new tests going to wind up on old perl and libnet versions? I understood that as Graham being unsure about using Test::More in the tests. Actually I was refering to Mock::Socket Graham.
Re: [PATCH lib/Net/Config.pm, MANIFEST, t/lib/Mock/Socket.pm, lib/Net/Config.t] Add Tests for Net::Config
Here's a test suite for Net::Config. In the process of writing this, I've fixed an apparent bug that prevented single values from becoming array references when necessary. I think it's right, but perhaps Graham should weigh in on this. In the process, with some advice from perl-qa, I've added a mock object so the test could control the output of Socket::inet_ntoa() and Socket::inet_aton(). t/lib/Mock/ seemed like as good a place as any. I'm not convinced. By setting up mock-ups you are not testing the real thing: you are testing mock-ups. It's real emptying shotguns at decoys and concluding that yup, we are eating duck tonight. Testing that the netconfig file works right with the %Netconfig is nice I think somewhat beside the point. The format of the file is irrelevant for the *outward* functionality of libnet. FWIW, I'm happy with leaving libnet essentially untested because I think by its very nature it is untestable across all the possible network configurations. Try some time using ftp from behind sadistic firewalls, for example. Situations like this *can* be configured to work, most of the time, but it requires a lot of off-line head scratching, bribing the keepers of the firewalls, things like that. Things a test suite cannot do unless we make Perl pass the Turing test. QA incendiary: I think rabidly trying to strap a test harness on everything that moves is counterproductive. Not all APIs have been planned to be tested. Of course the documentation should tell what are the public interfaces, but if in doubt, *ask* the author. Testing for internal not-meant-to-be-seen bits is plain silly. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
