On Wed, Mar 10, 2010 at 8:43 PM, Steve Bertrand <st...@ibctech.ca> wrote:
> Hi all,
>
> I've got a module that has a significant number of unit tests for each
> sub, each within its own file:
>
> acct-dev: ISP-RADIUS % ls t | grep daily
> 07-aggregate_daily.t
>
> Within the overall package, I've included a few utility scripts that are
> installed into the OS path that utilize these subs.
>
> Although the utility scripts are very short code-wise, I'd like to
> execute tests against them for their return values, aside from the
> direct testing of the methods that they call.
>
> From within a .t test, is there a preferred way to call a script so that
> it simulates the command-line itself?
>
Hi Steve,
Not really; there are too many variables. What OS? What shell? Does
the user the test runs as have permission to execute the file?
You can certainly write a test that uses backticks to capture the
output of a command, or you could your IPC::Open3 or Expect for
interactive testing of commands.
That sort of testnig, though, will only tell you if your Perl is
correct if the script is installed and correctly and executable. Your
unit tests should already be telling you that, so testing the scripts
themselves in this way seems somewhat redundant.
Your better course IMNSHO would be to construct environment and file
tests. Does the file exist in the specified location? Is it executable
by the current user? It is not writable? Is the enclosing directory in
$ENV{PATH}? Etc. (assuming you're on some flavor of Unix, of course).
If the Perl passes the unit tests and the files pass the file tests,
then move on to interactive testing if you want to.
HTH,
-- jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
values of β will give rise to dom!
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
