Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

tagg (277)

  (email not shown publicly)

Lars Thegler works for a danish telco, hacking Perl, and then some...

Journal of tagg (277)

Friday May 09, 2003
02:36 AM

Testing testing

[ #12090 ]

Hm. My Log::Dispatch::SNMP module is coming along nicely, but it'll be a bitch to test. My problem is whether I should just test my own bits (the interfaces to Log::Dispatch and Net::SNMP), or to do actual end-to-end testing.

End-to-end testing would mean starting up an SNMP trap receipient, send some log messages, and verify that they make it though the chain as expected. And then start changing parameters, exploring the whole parameter space.

My current development setup uses snmptrapd from Net-SNMP (not to be confused with Net::SNMP). But I really hate relying on external programs for testing.

Maybe I should just do whatever selfcontained testing I can, and leave the end-to-end stuff in a separate directory.

Or maybe I can concoct a trap receipient using some simplistic UDP server code with a bit of Convert::BER tacked on, but I'm afraid that down that road lies madness...

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • If we look at your complete setup I would recommend trusting the 3rd. party components, which would leave us with a sort of 'blackbox' test. It would be easy to implement and would bring you a long way.

    Start using your module somewhere and if you encounter problems/bugs start writing tests that show produce the bugs and then let these tests drill all the way have a 'whitebox' test approach.

    This was also the conclusion on the discussion after my test strategy presentation at the SPW [].