jk2addict has asked for the wisdom of the Perl Monks concerning the following question:

Greets to all. Hope the new year is treating everyone ok.

I'm currently writing a set of client side modules to interface with some 3rd party connectivity software we have running on our mainframe. The client software in that package was a windows only dll, so some packet sniffing and perl coding and I now have a perl client for *nix. :-) But I digress.

Even though these module will probably never hit the public, I'm forcing myself to Do The Right Thing by completing the inline pod, putting it all in a CPAN style package, etc. The last thing on my plate is the module tests, which leads me to my real question.

What would be the most sensible way to do test for these modules? I would either need to do pre-test config questions to get connect info to a live server, or I could write a tcp server module that mimics the real server.

I've looked into Net::Server and NetServer::Generic and while none of it looks terribly difficult, I have no idea where to start. Would it be better to run a 'simple'/'single' server within the test script, or should I just bite the bullet and write a real ::Server module to accompany the ::Client modules in this package? I guess they would be useful from the standpoint that new application mocksups could be built locally using the client and server parts without the 'real' server parts being available yet. What's the best way to have a client and server talking to each other within the same script?

I know. I know. "Network Programming with Perl". It's ordered and on the way. :-) I just want to get a head start.

Thanks,
-=Chris

  • Comment on Best Approach: package module tests with tcp

Replies are listed 'Best First'.
Re: Best Approach: package module tests with tcp
by chromatic (Archbishop) on Jan 10, 2003 at 22:07 UTC

    Test everything in isolation. That usually means test each function and method separately. For something complicated, you'll want to test as many pieces together as possible, but I never do that before I've tested everything in isolation.

    If I were doing this, I'd pull out the trusty Test::MockObject, fake up a network client (since it now works with blessed filehandles, you're golden), and test the slimmest bits of network code as possible.

    Another option is to have Makefile.PL check if you're in interactive mode and prompt to connect to a known server. That's a good integration test -- it's what CPAN does.

    My first answer is still, "test each piece individually" because most of your code doesn't actually rely on the network.

[reply]

      My apologies, but how to test using Test::MockObject seems simple according to the documentation. Where I fall down however is what and how to test in context.

      Testing an object that munges text or does calculations is pretty straight forward I would think. You know the in and out going into the test. But what about a network client in which there isn't one method to test, but instead it's the whole connect/send/receive/disconnet conversation that needs to be tested? It is at that point that I don't understand or have a clue where to start, esp without a server to conect to or a mock server to use.

      -=Chris

[reply]

        If something's hard to test, that's a sign that it could be simpler. Break it into smaller pieces based on logical behavior. If you have a function that connects to a socket and logs some data and prints some data, turn it into three functions.

        I'd start with the functions that only expect a live socket connection to be passed in, mock one up, and see what happens there.

[reply]
Re: Best Approach: package module tests with tcp
by adrianh (Chancellor) on Jan 11, 2003 at 12:39 UTC

    I second chromatic's suggestion of using Test::MockObject, but as a happy drinker of the Test First Design cool aid I have to comment on:

    The last thing on my plate is the module tests

    Try writing the tests first next time - I think you'll like the results. If your experience matches mine you'll get darn high test coverage, and end up with more robust code.

[reply]

Back to Seekers of Perl Wisdom