$EXE_SHELL should only be used with out own programs, not with
surrounding programs such as the perl interpreter.
Reviewed-by: Matt Caswell <matt@openssl.org>
Since we're building some of our perl scripts and the result might not
end up in apps/ (*), we may need to treat them like the compile
programs we use for testing.
This introduces perlapp() and perltest(), which behave like app() and
test(), but will add the perl executable in the command line.
-----
(*) For example, with a mk1mf build, the result will end up in $(BIN_D)
Reviewed-by: Matt Caswell <matt@openssl.org>
Enhances the routines in OpenSSL::Test::Utils for checking disabled
stuff to get their information directly from Configure instead of
'openssl list -disabled'.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
On VMS, the command MCR will assume SYS$SYSTEM: when the first
argument lacks a directory spec. So for programs in the current
directory, we add [] to tell MCR it is in the current directory.
It's the same as having ./ at the start of a program on Unix so the
shell doesn't start looking along $PATH.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Add Utils.pm for test utilities. This currently just contains one function:
disabled which checks if a feature is disabled based on the output of
openssl list -disabled
Reviewed-by: Richard Levitte <levitte@openssl.org>
If a test recipe does something like this:
indir "foo.$$" => sub {
chmod 0500, File::Spec->curdir();
ok(run(app(["something"])));
}
we get a problem, because we were storing the temporary stderr file in
the current directory at all times (so while inside the 'indir', we
would attemp to store it in "foo.$$").
So, change our ways to always store that temporary file in the exact
same location, defined by the environment variable RESULT_D, or
failing that TEST_D, or failing that $TOP/test.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Be careful when shifting in a function argument, you end up changing
the caller's value. Instead, when it is an array, make a shallow copy
and shift in that instead.
Reviewed-by: Rich Salz <rsalz@openssl.org>
It became tedious as well as error prone to have all recipes use
Test::More as well as OpenSSL::Test. The easier way is to make
OpenSSL::Test an extension of Test::More, thereby having all version
checks as well as future checks firmly there. Additionally, that
allows us to extend existing Test::More functions if the need would
arise.
Reviewed-by: Rich Salz <rsalz@openssl.org>
When the environment variable STOPTEST is defined (with any value other
than the empty string), the test machinery in OpenSSL::Test goes into a
different mode that will stop all testing at the end of a failing recipe.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Very simple test recipes easily become tedious, so they might benefit
from being made as simple as possible. Therefore, OpenSSL::Test::Simple
is born. It currently provides but one function, simple_test(), which
takes a minimum of two parameters (test name and program to run), with
the optional third, being the algorithm to be checked for before
running the test itself.
All recipes with that simple thing to do have been rewritten to be as
minimal as possible.
Reviewed-by: Rich Salz <rsalz@openssl.org>
The idea with this perl based testing framework is to make use of
what's delivered with perl and exists on all sorts of platforms.
The choice came to using Test::More and Test::Harness, as that seems
to be the most widely spread foundation, even if perl is aged.
The main runner of the show is run_tests.pl. As it currently stands,
it's designed to run from inside Makefile, but it's absolutely
possible to run it from the command line as well, like so:
cd test
OPENSSL_SRCDIR=.. perl run_tests.pl
The tester scripts themselves are stored in the subdirectory recipes/,
and initially, we have two such scripts, recipes/00-check_testalltests.t
and recipes/00-check_testexes.t. recipes/00-check_testalltests.t will
pick out the dependencies of "alltests" in test/Makefile, and check if
it can find recipes with corresponding names. recipes/00-check_testexes.t
does something similar, but bases it on existing compiled test binaries.
They make it easy to figure out what's to be added, and will be
removed when this effort is finished.
Individual recipes can be run as well, of course, as they are perl
scripts in themselves. For example, you can run only
recipes/00-check_testexes.t like so:
cd test
OPENSSL_SRCDIR=.. perl recipes/00-check_testexes.t
To make coding easier, there's a routine library OpenSSL::Test, which
is reachable in a perl script like so:
use lib 'testlib';
use OpenSSL::Test;
Reviewed-by: Rich Salz <rsalz@openssl.org>
