>they don't seem to check that the executable runs
They do check, and with every test.
Here are the comments from the first of many pp tests within
contrib\automated_pp_test.pl
#--------------------------------------------------------------------
# Test of 'pp hello'
# The command should: # Pack 'hello' into executable 'a.exe'
#
# . Create the file "hello" with the code that will
# print out the word "hello".
# . system pp hello
# a.exe will be created on windows
# . pipe 'a' and collect the results.
#
# Success if the result is "hello", failure otherwise.
#--------------------------------------------------------------------
As with most if not all pp tests, the stated pp test will first chdir to
the test dir, create a desired perl file such as "hello.pl", and then
"system" the desired pp command to create an executable within the test
directory.
Once the executable is created there is a routine called pipe_a_command
that is invoked with enough parameters to tell the pipe_a_command
routine what to do, amonst the parameters being the name of the newly
created executable to be found in the said test dir, and also the
expected results that should be gotten from running the executable.
Within pipe_a_command, this code gets reached:
$cmd = "$command_string $executable_name";
Still within pipe_a_command, a log file is opened up to hold data. The
$cmd is then sent to a pipe for execution. The stdout and stderr of the
pipe are captured and printed to the said log file. When finished, the
log file is examined for the expected results.
Again, all of this takes a lot of time, especially since many
combinations of pp switches are tested.
>content of manifest, and various other things which pp requires M::SD
to do correctly.
You are correct.
>introduces a lot of overhead into the tests
Yes, it does. Each and every pp test must first create the executable,
which takes a lot of time, and then execute the executable, which also
takes a lot of time, and then checks the results, etcetera. As long as
creating and executing takes up a lot of time, the tests for it will
also take up a lot of time.
Eric Wilhelm wrote:
Hello par users,
I'm looking at a few things in the guts of Module::ScanDeps and could
really use some suggestions, sample data, and volunteers to flesh out
the test suite.
I notice that PAR::Packer has quite a few pp tests in the contrib dir,
but they don't seem to check that the executable runs, content of
manifest, and various other things which pp requires M::SD to do
correctly. Besides not really providing much coverage, it also
introduces a lot of overhead into the tests.
Any suggestions? Particularly, _compile() and _execute() need some
love. Also, all of the module-specific knowledge in %Preload sort of
scares me. How to get test coverage on that?
Thanks,
Eric
