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

I wrote a module that is a wrapper to a CLI for a web service. I've already written tests to cover the basic operation of the module for my specific environment where I know the CLI is installed and can see the exact output that can be expected from the CLI. I'm now in a position of thinking about what tests I need to ensure the module still works on versions of the CLI written on other systems and I'm trying to map out a general approach to these tests. I'd like to get some input from more seasoned monks on whether this makes sense and to avoid re-inventing the wheel.

First, I'm thinking if the CLI tool my module requires is not installed on a system or it is not up-to-date, I still want to install the module without failure (the user can always install or upgrade their CLI after installing my module) and skip the tests requiring the actual CLI. I plan on using some mocked up data to run the tests if it is not installed or if the CLI utility is not current. Alternatively, I could just abort the installation. I'm not sure what the best approach would be here and I'd greatly appreciate some thoughts on this.

But let's say I go with the first option and allow them to install my module without the CLI installed. When the user first fires up my module, I'm thinking I should prompt them to run the tests with the actual CLI installed. I'm thinking my module will check the status of a some kind of simple flag (maybe by the existence of file) and if it's not present, it will ask the user if they want to run the tests. After the tests run successfully, it'll set the flag to true and not prompt them again. But perhaps this is overkill? Maybe I should just ensure the output from the CLI is what is expected and abort any operation if it isn't what is expected?

TIA. I could have never gotten to this point without all the great monks here on PM!

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

  • Comment on Post installation tests for a wrapper to a CLI utility?

Replies are listed 'Best First'.
Re: Post installation tests for a wrapper to a CLI utility?
by stevieb (Canon) on Jan 31, 2018 at 02:22 UTC

    I would set up as many VMs as possible, each one set up to continuously test the distribution against a different version of the CLI automatically. It's even easier if you can install multiple versions on one machine. You usually can't support all versions of a binary of course, but if you have decent coverage across a reasonable number of versions, things should go well.

    In your Makefile.PL (or alternate build system setup file), you can do a check and just die() if the version of the CLI on the client system does not conform to one of the versions that your tests pass against. If the CLI has a --version flag for instance, this is trivially easy to support.

    By the sounds of it, the CLI is something installed by the client and used in production, so I would loudly advise against (ie. don't do it!) copying in the new CLI onto a system. Instead, advise the installer of the distribution when you stop the install process that their version of the CLI is/can not be supported, and they need to upgrade, and display the version options they have.

    Here's an example where I check for a binary (perlbrew or berrybrew depending on OS-type). I don't exit, I just warn that we'll install anyways, but the Perl "binaries" I'm about to install to use the distribution's modules simply won't work (because they won't work period and it'll be clear; this isn't a situation where it may partly work, but other things could cause detrimental issues. If it were, I'd hard exit).

[reply]
[d/l]
[select]

      Thanks!

      Here's a 101 type question wrt Windows. I don't know much about Perl on Windows. I played around with ActiveState Perl like 15 years ago and that's about the extent of my knowledge. I do have access to a Windows 8 machine in VirtualBox which does not have Perl installed. What are the basic steps I need to take to install my module on that machine manually (it's not yet available on CPAN) to be able to run tests on it? Also, do I need to worry about differences between Window 8 and Windows 10 or any other flavor of Windows? And is Active State Perl still the standard? I know there is Strawberry Perl now.

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate Priest";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

[reply]

        ActiveState has never been a standard. Make life easy on yourself, just install Strawberry, and use cpanm (cpanm . within the directory containing your module) to install & test your modules.

[reply]
[d/l]
[reply]

        Third marto, and second soonix - I moved to Strawberry back in 2008 and never looked back. I use Perl pretty much exclusively on Windows and unless a module is specifically written for *nix, Strawberry works great, installs from CPAN and just works. As a side note, the bundled GCC compiler let's me write and compile the (fairly small amount) of C programming I do.

[reply]
        This group is heavily biased towards Strawberry. I am still using ActivePerl as do some other Monks. ActivePerl is certainly not a "standard". I don't think that Strawberry qualifies either. However, both will work just fine.

        I often write code that other folks need to run on their Windows machines. Some of these folks don't know much if anything at all about Perl and aren't used to working with a command line. The ActiveState installation process on Windows is straightforward and the latest incarnations work well. With ActivePerl, I can generate an XML package file. I give my user the command to run this file and result is that my installation is "cloned" - the user now has my entire dev environment via a single step. With a pre-compiled and tested ActiveState .ppd files, the installation goes quickly - the longest part is generating the local HTML documentation files.

        With ActiveState, you can install the ActiveState cpan module and this comes with the correct compiler to make "from scratch" binary compatible modules (perhaps including XS parts) to the standard distribution.

        Anway just saying in some situations, ActivePerl can work out well.

[reply]

Back to Seekers of Perl Wisdom