Skip to content

Time to get back to my roots: Perl

Today I wrote a perl Test::RemoteServer module:

#!/usr/bin/perl -w -I.

use strict;
use warnings;

use Test::More tests => 4;
use Test::RemoteServer;

#
#  Ping Tests
#
ping_ok( "192.168.0.1",       "Website host is up: IPv4" );
ping6_ok( "www.steve.org.uk", "Website host is up: IPv6" );

#
#  Socket tests
#
socket_open( "ipv4.steve.org.uk", "2222", "OpenSSH is running" );
socket_closed( "ipv4.steve.org.uk", "22", "OpenSSH is not available on :22" );

I can see a lot of value in defining tests that are carried out against remote hosts - even if they're more basic than the kind of comprehensive testing you'd get via Custodian, Nagios, etc.

Being able to run "make test" and remotely probe services is cool.

Unfortunately I suspect the new-hotness is to couple the testing with your Chef, Puppet, CFengine, Slaughter, Ansible, etc, policies. That way you have two things:

  • A consistent way to define system-state.
  • A consistent way to test that the damn thing worked.

Coming to CPAN in the near future anyway, I can throw it up on Github in advance if there is any interest..

Comments On This Entry

  1. [gravitar] Chris

    Don't post this on CPAN. It doesn't really belong there, as it's more for modules than one-off scripts0. And there are some fixes you should make before posting it anywhere else, as well.

    The first one to jump out at me is that you're using `-w`. This flag was deprecated years ago in favor of warnings.pm. See `perldoc perllexwarn` for more information.

    Don't specify a test count to Test::More's `import`. The better approach is to use `done_testing`. This signals to the testing harness that you're finished testing. This is better than specifying a count in a variety of ways. First, it frees you from having to count the tests you're going to run. Second, in the event of a test harness failure or test script failure, it's immediately apparent that this happened. Third, in the event that tests execute after `done_testing`, this is either obviously a bug or something you should definitely investigate.

    Additionally, I would remove the `-I.` from the shebang and rely on the $PERL5INC environment variable to find the required libraries. Just as you should never ever set PATH to include `.`, so too should you never add `.` to @INC, for many of the same reasons.

    [0]: Yes, years and years ago various people posted scripts to CPAN, but this was ages before things like github and the App:: namepsace existed. Both of these are better-suited to what you want to accomplish.

  2. [author] Steve Kemp

    Chris, to be clear, the thing that I uploaded to CPAN was the actual meat - the Test::RemoteServer module.

    The code above was just sample code showing how it could be used, and how you could write simple tests with it.

    As for the -Ilib/, that's just a temporary thing, before the module was installed system-wide.

    That said the done_testing was new to me, so thanks for that.

  3. [gravitar] Brian

    If you haven't already, take a look at the similar project serverspec.

    http://serverspec.org/

  4. [author] Steve Kemp

    Server Spec looks awesome, and it is great the way it runs via SSH too.

    Thanks for sharing the link!