in reply to Portably unit testing scripts

I could actually execute the script, but that isn't much of a "unit" test anymore

Why not? As you said, it's a thin wrapper around your library, and I assume you've got plenty of tests for that, so you've got that covered. The script is an interface between the command line and the library, and that's the "unit" you're testing here - IMHO actually executing Perl is the only "real" way to test it. In any case, don't be too strict with yourself regarding the formal definitions of "unit" and "integration" tests here - while certainly important in some contexts (e.g. large projects with multiple devs), IMHO the far more important metrics here are whether you're testing everything, as in code coverage and so on.

I have various command-line tools that I test, see e.g. t/ in htools, although in that particular repository I haven't tested them on Windows. For that, you could take a look at the tests for my Badge::Simple command-line tool, or perhaps even more closely related to your question, this test for my Shell::Tools. Here's a short example for your script, assuming it's in a bin subdir and the tests in a t subdir, and if the script actually had a Synopsis POD. Running prove on this works on Linux and on Windows.

#!/usr/bin/env perl use warnings; use strict; use FindBin; use File::Spec::Functions qw/catfile updir/; use Capture::Tiny 'capture'; use Config; use Test::More tests => 2; # Unit Under Test my $UUT = catfile($FindBin::Bin, updir, 'bin', 'foo.pl'); subtest '--version' => sub { plan tests => 3; my ($out,$err,$exit) = capture { system $Config{perlpath}, $UUT, '--version' }; is $exit, 0, 'perl ok'; is $out, "my_script version 1.00\n\n", 'stdout message correct'; is $err, '', 'no stderr'; }; subtest '--help' => sub { plan tests => 3; my ($out,$err,$exit) = capture { system $Config{perlpath}, $UUT, '--help' }; is $exit, 0, 'perl ok'; like $out, qr/\bUsage:\s+foo\.pl FOO BAR\b/si, 'stdout message correct'; is $err, '', 'no stderr'; };

(Note: I've often used $^X instead of Config's perlpath without problems, but the CPAN Authors FAQ recommends the latter.)

Replies are listed 'Best First'.
Re^2: Portably unit testing scripts
by wanna_code_perl (Friar) on Oct 26, 2019 at 09:39 UTC
    IMHO the far more important metrics here are whether you're testing everything, as in code coverage and so on.

    Yes, you seem to understand what I'm trying to do: I want to test everything adequately (and part of that is code coverage). Portability is a very important concern. In fact, my main reservation about using $^X, system, Capture::Tiny, etc, (which is very similar to what I used to do for in-house releases for known platforms) is a concern, potentially unfounded, that I might artificially limit the platforms my distribution will install on. On the one hand, maybe I am worried for nothing, but on the other hand, I'd hate for my entire module installation to fail because a test for the script did not succeed, when the library itself would have tested and installed just fine.

    Thanks for the link to your distributions that use a similar approach. Those CPAN testers matrices give me hope that I might be worried for no good reason.

    I know there is more I could do, but a lesser desire is that I keep my finite efforts focused on the library itself, with proportionately less time spent on some 40-line script I am including as a useful afterthought. But, hey, that's software sometimes, I suppose.

      I might artificially limit the platforms my distribution will install on

      Yeah, I like portability myself, and I had the same worry when I started releasing CPAN modules, but experience has shown me that portability is possible. And even if you release a module and it initially fails on a bunch of CPAN Testers, it's possible to bring it back to 100%. As you probably saw, the Shell::Tools tests (which my example code above is based on) pass on Cygwin, Darwin (Mac OS X), FreeBSD, GNU/kFreeBSD, Haiku, Linux, MSWin32, NetBSD, OpenBSD, and Solaris.

Re^2: Portably unit testing scripts
by Anonymous Monk on Oct 26, 2019 at 08:34 UTC
    The thing about $^X is shocking / unconvincing / inadequately documented. In a test suite $^X is always absolute.
      uh, what?