in reply to Re^3: How to write testable command line script?
in thread How to write testable command line script?

I appreciate your effort but this is my confusion: The script works correctly at the command line and does not issue any warnings, despite use of the strict and warnings pragmas enabled. It is only when I try to run it using automated test tools do those warnings arise.

Example: If I simply call reduce with 1 argument at the command line, it will be pushed onto the @answer array and returned.

This tells me that the instantiation errors are in the way the test code interfaces with the code under test. I don't understand why the arguments aren't being passed to the appropriate subroutine.

If I attempt to pass a list of scalar arguments in the test code, I get syntax errors when I run: 

perl -c test_file.t

[download]

Also:

  • 1. What should I be doing in the return statements of this particular subroutine so they are easier to test?
  • 2. Should I be testing the subroutine individually, or indirectly accessing the sub through a call to main, as it appears to be done in the Perl Testing: A Developer's Notebook example?

    • Replies are listed 'Best First'.
    Re^5: How to write testable command line script?
    by GrandFather (Saint) on Nov 21, 2018 at 02:27 UTC

      Oh! Silly me. You call:

      main('90   35  29 + 90  24 29')

      [download]

      But main is:

      sub main {
    reduce(@ARGV);
}

      [download]

      so reduce doesn't see the parameters passed to main, it sees @ARGV which is empty. Change main to:

      sub main {
    reduce(@_);
}

      [download]

      Also:

      1. Whatever is natural for the sub. Because of its recursive implementation returning anything except a list from reduce doesn't make sense.
      2. There are two different test modes: Functional testing where you test the whole system works as a whole - call main, and unit testing where you test individual units work as advertised - call reduce.

      In this case "the whole" is a trivial wrapper around reduce so I'd go for testing reduce directly - a unit test.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
    		[reply]
    [d/l]
    [select]

        You last reply was very helpful! Running the test code manually, my debug print statements in the *.pl file show that the @answer array continues to contain the values from previous calls:

      • Test 1. @answer array returns 180 59 58 (test passes).
      • Test 2. @answer array returns 179 1 9 180 59 58 (test fails).
      • Test 3. @answer array returns 180 0 0 179 1 9 180 59 58 (test fails).
        • I tried adding 
        my @answer = undef;

        [download]
        to the test file main sub definition (thinking that this would get cleared on every call) but that did not work. What do you suggest now?

    		[reply]
    [d/l]
          my @answer = undef;

          General note: I'm not sure what you intend by the quoted statement, but you should realize that it initializes the (newly created) array with a single element, the undef value, which in Perl is a well-defined value! (The  @answer array thus created is also entirely and absolutely independent of any other array with the same name.) 

          c:\@Work\Perl\monks>perl -wMstrict -le
"use Data::Dump qw(dd);
 ;;
 my @answer = undef;
 dd \@answer;
"
[undef]

          [download]

          Give a man a fish:  <%-{-{-{-<

    		[reply]
    [d/l]
    [select]

    In Section Seekers of Perl Wisdom