Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
package OpenSSL::Test;
|
|
|
|
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
|
2015-04-30 06:51:24 +00:00
|
|
|
use Test::More 0.96;
|
|
|
|
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
use Exporter;
|
|
|
|
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
|
2016-01-30 00:05:33 +00:00
|
|
|
$VERSION = "0.8";
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
@ISA = qw(Exporter);
|
2016-01-26 13:57:21 +00:00
|
|
|
@EXPORT = (@Test::More::EXPORT, qw(setup indir app perlapp test perltest run));
|
2016-01-30 00:05:33 +00:00
|
|
|
@EXPORT_OK = (@Test::More::EXPORT_OK, qw(bldtop_dir bldtop_file
|
|
|
|
srctop_dir srctop_file
|
|
|
|
pipe with cmdstr quotify));
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=head1 NAME
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
OpenSSL::Test - a private extension of Test::More
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=head1 SYNOPSIS
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
use OpenSSL::Test;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
setup("my_test_name");
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
ok(run(app(["openssl", "version"])), "check for openssl presence");
|
2015-04-29 19:51:25 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
indir "subdir" => sub {
|
|
|
|
ok(run(test(["sometest", "arg1"], stdout => "foo.txt")),
|
|
|
|
"run sometest with output to foo.txt");
|
|
|
|
};
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=head1 DESCRIPTION
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
This module is a private extension of L<Test::More> for testing OpenSSL.
|
|
|
|
In addition to the Test::More functions, it also provides functions that
|
|
|
|
easily find the diverse programs within a OpenSSL build tree, as well as
|
|
|
|
some other useful functions.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
This module I<depends> on the environment variables C<$TOP> or C<$SRCTOP>
|
|
|
|
and C<$BLDTOP>. Without one of the combinations it refuses to work.
|
|
|
|
See L</ENVIRONMENT> below.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
use File::Copy;
|
|
|
|
use File::Spec::Functions qw/file_name_is_absolute curdir canonpath splitdir
|
|
|
|
catdir catfile splitpath catpath devnull abs2rel
|
|
|
|
rel2abs/;
|
2016-02-08 15:44:48 +00:00
|
|
|
use File::Path 2.00 qw/rmtree mkpath/;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# The name of the test. This is set by setup() and is used in the other
|
|
|
|
# functions to verify that setup() has been used.
|
|
|
|
my $test_name = undef;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# Directories we want to keep track of TOP, APPS, TEST and RESULTS are the
|
|
|
|
# ones we're interested in, corresponding to the environment variables TOP
|
2016-01-30 00:05:33 +00:00
|
|
|
# (mandatory), BIN_D, TEST_D, UTIL_D and RESULT_D.
|
2015-04-30 12:30:15 +00:00
|
|
|
my %directories = ();
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2016-04-07 12:30:15 +00:00
|
|
|
# The environment variables that gave us the contents in %directories. These
|
|
|
|
# get modified whenever we change directories, so that subprocesses can use
|
|
|
|
# the values of those environment variables as well
|
|
|
|
my @direnv = ();
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# A bool saying if we shall stop all testing if the current recipe has failing
|
|
|
|
# tests or not. This is set by setup() if the environment variable STOPTEST
|
|
|
|
# is defined with a non-empty value.
|
|
|
|
my $end_with_bailout = 0;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# A set of hooks that is affected by with() and may be used in diverse places.
|
|
|
|
# All hooks are expected to be CODE references.
|
|
|
|
my %hooks = (
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# exit_checker is used by run() directly after completion of a command.
|
|
|
|
# it receives the exit code from that command and is expected to return
|
|
|
|
# 1 (for success) or 0 (for failure). This is the value that will be
|
|
|
|
# returned by run().
|
|
|
|
# NOTE: When run() gets the option 'capture => 1', this hook is ignored.
|
|
|
|
exit_checker => sub { return shift == 0 ? 1 : 0 },
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
);
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
# Debug flag, to be set manually when needed
|
|
|
|
my $debug = 0;
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# Declare some utility functions that are defined at the end
|
2016-01-30 00:05:33 +00:00
|
|
|
sub bldtop_file;
|
|
|
|
sub bldtop_dir;
|
|
|
|
sub srctop_file;
|
|
|
|
sub srctop_dir;
|
2015-04-30 12:30:15 +00:00
|
|
|
sub quotify;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
# Declare some private functions that are defined at the end
|
|
|
|
sub __env;
|
|
|
|
sub __cwd;
|
|
|
|
sub __apps_file;
|
|
|
|
sub __results_file;
|
|
|
|
sub __fixup_cmd;
|
|
|
|
sub __build_cmd;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=head2 Main functions
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
The following functions are exported by default when using C<OpenSSL::Test>.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<setup "NAME">
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
C<setup> is used for initial setup, and it is mandatory that it's used.
|
|
|
|
If it's not used in a OpenSSL test recipe, the rest of the recipe will
|
|
|
|
most likely refuse to run.
|
|
|
|
|
|
|
|
C<setup> checks for environment variables (see L</ENVIRONMENT> below),
|
2016-01-30 00:05:33 +00:00
|
|
|
checks that C<$TOP/Configure> or C<$SRCTOP/Configure> exists, C<chdir>
|
|
|
|
into the results directory (defined by the C<$RESULT_D> environment
|
|
|
|
variable if defined, otherwise C<$BLDTOP/test> or C<$TOP/test>, whichever
|
|
|
|
is defined).
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
sub setup {
|
2016-03-05 18:05:25 +00:00
|
|
|
my $old_test_name = $test_name;
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
$test_name = shift;
|
|
|
|
|
|
|
|
BAIL_OUT("setup() must receive a name") unless $test_name;
|
2016-03-05 18:05:25 +00:00
|
|
|
warn "setup() detected test name change. Innocuous, so we continue...\n"
|
|
|
|
if $old_test_name && $old_test_name ne $test_name;
|
|
|
|
|
|
|
|
return if $old_test_name;
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
BAIL_OUT("setup() needs \$TOP or \$SRCTOP and \$BLDTOP to be defined")
|
|
|
|
unless $ENV{TOP} || ($ENV{SRCTOP} && $ENV{BLDTOP});
|
|
|
|
BAIL_OUT("setup() found both \$TOP and \$SRCTOP or \$BLDTOP...")
|
|
|
|
if $ENV{TOP} && ($ENV{SRCTOP} || $ENV{BLDTOP});
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
__env();
|
2015-04-29 19:51:25 +00:00
|
|
|
|
2016-03-05 18:05:25 +00:00
|
|
|
BAIL_OUT("setup() expects the file Configure in the source top directory")
|
|
|
|
unless -f srctop_file("Configure");
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
__cwd($directories{RESULTS});
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<indir "SUBDIR" =E<gt> sub BLOCK, OPTS>
|
|
|
|
|
|
|
|
C<indir> is used to run a part of the recipe in a different directory than
|
|
|
|
the one C<setup> moved into, usually a subdirectory, given by SUBDIR.
|
|
|
|
The part of the recipe that's run there is given by the codeblock BLOCK.
|
|
|
|
|
|
|
|
C<indir> takes some additional options OPTS that affect the subdirectory:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<create =E<gt> 0|1>
|
|
|
|
|
|
|
|
When set to 1 (or any value that perl preceives as true), the subdirectory
|
|
|
|
will be created if it doesn't already exist. This happens before BLOCK
|
|
|
|
is executed.
|
|
|
|
|
|
|
|
=item B<cleanup =E<gt> 0|1>
|
|
|
|
|
|
|
|
When set to 1 (or any value that perl preceives as true), the subdirectory
|
|
|
|
will be cleaned out and removed. This happens both before and after BLOCK
|
|
|
|
is executed.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
An example:
|
|
|
|
|
|
|
|
indir "foo" => sub {
|
|
|
|
ok(run(app(["openssl", "version"]), stdout => "foo.txt"));
|
|
|
|
if (ok(open(RESULT, "foo.txt"), "reading foo.txt")) {
|
|
|
|
my $line = <RESULT>;
|
|
|
|
close RESULT;
|
|
|
|
is($line, qr/^OpenSSL 1\./,
|
|
|
|
"check that we're using OpenSSL 1.x.x");
|
|
|
|
}
|
|
|
|
}, create => 1, cleanup => 1;
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
sub indir {
|
|
|
|
my $subdir = shift;
|
|
|
|
my $codeblock = shift;
|
|
|
|
my %opts = @_;
|
|
|
|
|
|
|
|
my $reverse = __cwd($subdir,%opts);
|
|
|
|
BAIL_OUT("FAILURE: indir, \"$subdir\" wasn't possible to move into")
|
|
|
|
unless $reverse;
|
|
|
|
|
|
|
|
$codeblock->();
|
|
|
|
|
|
|
|
__cwd($reverse);
|
|
|
|
|
|
|
|
if ($opts{cleanup}) {
|
2016-02-08 15:44:48 +00:00
|
|
|
rmtree($subdir, { safe => 0 });
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<app ARRAYREF, OPTS>
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<test ARRAYREF, OPTS>
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
Both of these functions take a reference to a list that is a command and
|
|
|
|
its arguments, and some additional options (described further on).
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
C<app> expects to find the given command (the first item in the given list
|
2016-01-30 00:05:33 +00:00
|
|
|
reference) as an executable in C<$BIN_D> (if defined, otherwise C<$TOP/apps>
|
|
|
|
or C<$BLDTOP/apps>).
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
C<test> expects to find the given command (the first item in the given list
|
2016-01-30 00:05:33 +00:00
|
|
|
reference) as an executable in C<$TEST_D> (if defined, otherwise C<$TOP/test>
|
|
|
|
or C<$BLDTOP/test>).
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
Both return a CODEREF to be used by C<run>, C<pipe> or C<cmdstr>.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
The options that both C<app> and C<test> can take are in the form of hash
|
|
|
|
values:
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<stdin =E<gt> PATH>
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<stdout =E<gt> PATH>
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<stderr =E<gt> PATH>
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
In all three cases, the corresponding standard input, output or error is
|
|
|
|
redirected from (for stdin) or to (for the others) a file given by the
|
|
|
|
string PATH, I<or>, if the value is C<undef>, C</dev/null> or similar.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=back
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
=item B<perlapp ARRAYREF, OPTS>
|
|
|
|
|
|
|
|
=item B<perltest ARRAYREF, OPTS>
|
|
|
|
|
|
|
|
Both these functions function the same way as B<app> and B<test>, except
|
2016-03-29 17:36:55 +00:00
|
|
|
that they expect the command to be a perl script. Also, they support one
|
|
|
|
more option:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<interpreter_args =E<gt> ARRAYref>
|
|
|
|
|
|
|
|
The array reference is a set of arguments for perl rather than the script.
|
|
|
|
Take care so that none of them can be seen as a script! Flags and their
|
|
|
|
eventual arguments only!
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
An example:
|
|
|
|
|
|
|
|
ok(run(perlapp(["foo.pl", "arg1"],
|
|
|
|
interpreter_args => [ "-I", srctop_dir("test") ])));
|
2016-01-26 13:57:21 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=back
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
sub app {
|
|
|
|
my $cmd = shift;
|
|
|
|
my %opts = @_;
|
|
|
|
return sub { my $num = shift;
|
|
|
|
return __build_cmd($num, \&__apps_file, $cmd, %opts); }
|
|
|
|
}
|
|
|
|
|
|
|
|
sub test {
|
|
|
|
my $cmd = shift;
|
|
|
|
my %opts = @_;
|
|
|
|
return sub { my $num = shift;
|
|
|
|
return __build_cmd($num, \&__test_file, $cmd, %opts); }
|
|
|
|
}
|
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
sub perlapp {
|
|
|
|
my $cmd = shift;
|
|
|
|
my %opts = @_;
|
|
|
|
return sub { my $num = shift;
|
|
|
|
return __build_cmd($num, \&__perlapps_file, $cmd, %opts); }
|
|
|
|
}
|
|
|
|
|
|
|
|
sub perltest {
|
|
|
|
my $cmd = shift;
|
|
|
|
my %opts = @_;
|
|
|
|
return sub { my $num = shift;
|
|
|
|
return __build_cmd($num, \&__perltest_file, $cmd, %opts); }
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=item B<run CODEREF, OPTS>
|
|
|
|
|
|
|
|
This CODEREF is expected to be the value return by C<app> or C<test>,
|
|
|
|
anything else will most likely cause an error unless you know what you're
|
|
|
|
doing.
|
|
|
|
|
|
|
|
C<run> executes the command returned by CODEREF and return either the
|
|
|
|
resulting output (if the option C<capture> is set true) or a boolean indicating
|
|
|
|
if the command succeeded or not.
|
|
|
|
|
|
|
|
The options that C<run> can take are in the form of hash values:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<capture =E<gt> 0|1>
|
|
|
|
|
|
|
|
If true, the command will be executed with a perl backtick, and C<run> will
|
|
|
|
return the resulting output as an array of lines. If false or not given,
|
|
|
|
the command will be executed with C<system()>, and C<run> will return 1 if
|
|
|
|
the command was successful or 0 if it wasn't.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
For further discussion on what is considered a successful command or not, see
|
|
|
|
the function C<with> further down.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
sub run {
|
2016-02-12 17:16:23 +00:00
|
|
|
my ($cmd, $display_cmd) = shift->(0);
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
my %opts = @_;
|
|
|
|
|
|
|
|
return () if !$cmd;
|
|
|
|
|
|
|
|
my $prefix = "";
|
|
|
|
if ( $^O eq "VMS" ) { # VMS
|
|
|
|
$prefix = "pipe ";
|
|
|
|
}
|
|
|
|
|
|
|
|
my @r = ();
|
|
|
|
my $r = 0;
|
|
|
|
my $e = 0;
|
2016-03-18 07:57:52 +00:00
|
|
|
|
|
|
|
# The dance we do with $? is the same dance the Unix shells appear to
|
|
|
|
# do. For example, a program that gets aborted (and therefore signals
|
|
|
|
# SIGABRT = 6) will appear to exit with the code 134. We mimic this
|
|
|
|
# to make it easier to compare with a manual run of the command.
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
if ($opts{capture}) {
|
|
|
|
@r = `$prefix$cmd`;
|
2016-03-18 07:57:52 +00:00
|
|
|
$e = ($? & 0x7f) ? ($? & 0x7f)|0x80 : ($? >> 8);
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
} else {
|
|
|
|
system("$prefix$cmd");
|
2016-03-18 07:57:52 +00:00
|
|
|
$e = ($? & 0x7f) ? ($? & 0x7f)|0x80 : ($? >> 8);
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
$r = $hooks{exit_checker}->($e);
|
|
|
|
}
|
|
|
|
|
2016-03-31 13:08:34 +00:00
|
|
|
print STDERR "$prefix$display_cmd => $e\n"
|
2016-03-29 17:43:33 +00:00
|
|
|
if !$ENV{HARNESS_ACTIVE} || $ENV{HARNESS_VERBOSE};
|
|
|
|
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
# At this point, $? stops being interesting, and unfortunately,
|
|
|
|
# there are Test::More versions that get picky if we leave it
|
|
|
|
# non-zero.
|
|
|
|
$? = 0;
|
|
|
|
|
|
|
|
if ($opts{capture}) {
|
|
|
|
return @r;
|
|
|
|
} else {
|
|
|
|
return $r;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
END {
|
|
|
|
my $tb = Test::More->builder;
|
|
|
|
my $failure = scalar(grep { $_ == 0; } $tb->summary);
|
|
|
|
if ($failure && $end_with_bailout) {
|
|
|
|
BAIL_OUT("Stoptest!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
=head2 Utility functions
|
|
|
|
|
|
|
|
The following functions are exported on request when using C<OpenSSL::Test>.
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
# To only get the bldtop_file and srctop_file functions.
|
|
|
|
use OpenSSL::Test qw/bldtop_file srctop_file/;
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
# To only get the bldtop_file function in addition to the default ones.
|
|
|
|
use OpenSSL::Test qw/:DEFAULT bldtop_file/;
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
# Utility functions, exported on request
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
=item B<bldtop_dir LIST>
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
LIST is a list of directories that make up a path from the top of the OpenSSL
|
2016-01-30 00:05:33 +00:00
|
|
|
build directory (as indicated by the environment variable C<$TOP> or
|
|
|
|
C<$BLDTOP>).
|
|
|
|
C<bldtop_dir> returns the resulting directory as a string, adapted to the local
|
2015-04-30 12:30:15 +00:00
|
|
|
operating system.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
sub bldtop_dir {
|
|
|
|
return __bldtop_dir(@_); # This caters for operating systems that have
|
2015-04-30 12:30:15 +00:00
|
|
|
# a very distinct syntax for directories.
|
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
=item B<bldtop_file LIST, FILENAME>
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
LIST is a list of directories that make up a path from the top of the OpenSSL
|
2016-01-30 00:05:33 +00:00
|
|
|
build directory (as indicated by the environment variable C<$TOP> or
|
|
|
|
C<$BLDTOP>) and FILENAME is the name of a file located in that directory path.
|
|
|
|
C<bldtop_file> returns the resulting file path as a string, adapted to the local
|
2015-04-30 12:30:15 +00:00
|
|
|
operating system.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
sub bldtop_file {
|
|
|
|
return __bldtop_file(@_);
|
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<srctop_dir LIST>
|
|
|
|
|
|
|
|
LIST is a list of directories that make up a path from the top of the OpenSSL
|
|
|
|
source directory (as indicated by the environment variable C<$TOP> or
|
|
|
|
C<$SRCTOP>).
|
|
|
|
C<srctop_dir> returns the resulting directory as a string, adapted to the local
|
|
|
|
operating system.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub srctop_dir {
|
|
|
|
return __srctop_dir(@_); # This caters for operating systems that have
|
|
|
|
# a very distinct syntax for directories.
|
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<srctop_file LIST, FILENAME>
|
|
|
|
|
|
|
|
LIST is a list of directories that make up a path from the top of the OpenSSL
|
|
|
|
source directory (as indicated by the environment variable C<$TOP> or
|
|
|
|
C<$SRCTOP>) and FILENAME is the name of a file located in that directory path.
|
|
|
|
C<srctop_file> returns the resulting file path as a string, adapted to the local
|
|
|
|
operating system.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub srctop_file {
|
|
|
|
return __srctop_file(@_);
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<pipe LIST>
|
|
|
|
|
|
|
|
LIST is a list of CODEREFs returned by C<app> or C<test>, from which C<pipe>
|
|
|
|
creates a new command composed of all the given commands put together in a
|
|
|
|
pipe. C<pipe> returns a new CODEREF in the same manner as C<app> or C<test>,
|
|
|
|
to be passed to C<run> for execution.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
sub pipe {
|
|
|
|
my @cmds = @_;
|
|
|
|
return
|
|
|
|
sub {
|
|
|
|
my @cs = ();
|
|
|
|
my @dcs = ();
|
|
|
|
my @els = ();
|
|
|
|
my $counter = 0;
|
|
|
|
foreach (@cmds) {
|
|
|
|
my ($c, $dc, @el) = $_->(++$counter);
|
|
|
|
|
|
|
|
return () if !$c;
|
|
|
|
|
|
|
|
push @cs, $c;
|
|
|
|
push @dcs, $dc;
|
|
|
|
push @els, @el;
|
|
|
|
}
|
|
|
|
return (
|
|
|
|
join(" | ", @cs),
|
|
|
|
join(" | ", @dcs),
|
|
|
|
@els
|
|
|
|
);
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<with HASHREF, CODEREF>
|
|
|
|
|
|
|
|
C<with> will temporarly install hooks given by the HASHREF and then execute
|
|
|
|
the given CODEREF. Hooks are usually expected to have a coderef as value.
|
|
|
|
|
|
|
|
The currently available hoosk are:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<exit_checker =E<gt> CODEREF>
|
|
|
|
|
|
|
|
This hook is executed after C<run> has performed its given command. The
|
|
|
|
CODEREF receives the exit code as only argument and is expected to return
|
|
|
|
1 (if the exit code indicated success) or 0 (if the exit code indicated
|
|
|
|
failure).
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub with {
|
|
|
|
my $opts = shift;
|
|
|
|
my %opts = %{$opts};
|
|
|
|
my $codeblock = shift;
|
|
|
|
|
|
|
|
my %saved_hooks = ();
|
|
|
|
|
|
|
|
foreach (keys %opts) {
|
|
|
|
$saved_hooks{$_} = $hooks{$_} if exists($hooks{$_});
|
|
|
|
$hooks{$_} = $opts{$_};
|
|
|
|
}
|
|
|
|
|
|
|
|
$codeblock->();
|
|
|
|
|
|
|
|
foreach (keys %saved_hooks) {
|
|
|
|
$hooks{$_} = $saved_hooks{$_};
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
2016-04-01 13:05:52 +00:00
|
|
|
=item B<cmdstr CODEREF, OPTS>
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
C<cmdstr> takes a CODEREF from C<app> or C<test> and simply returns the
|
|
|
|
command as a string.
|
|
|
|
|
2016-04-01 13:05:52 +00:00
|
|
|
C<cmdstr> takes some additiona options OPTS that affect the string returned:
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<display =E<gt> 0|1>
|
|
|
|
|
|
|
|
When set to 0, the returned string will be with all decorations, such as a
|
|
|
|
possible redirect of stderr to the null device. This is suitable if the
|
|
|
|
string is to be used directly in a recipe.
|
|
|
|
|
|
|
|
When set to 1, the returned string will be without extra decorations. This
|
|
|
|
is suitable for display if that is desired (doesn't confuse people with all
|
|
|
|
internal stuff), or if it's used to pass a command down to a subprocess.
|
|
|
|
|
|
|
|
Default: 0
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub cmdstr {
|
2016-02-12 17:16:23 +00:00
|
|
|
my ($cmd, $display_cmd) = shift->(0);
|
2016-04-01 13:05:52 +00:00
|
|
|
my %opts = @_;
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-04-01 13:05:52 +00:00
|
|
|
if ($opts{display}) {
|
|
|
|
return $display_cmd;
|
|
|
|
} else {
|
|
|
|
return $cmd;
|
|
|
|
}
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<quotify LIST>
|
|
|
|
|
|
|
|
LIST is a list of strings that are going to be used as arguments for a
|
|
|
|
command, and makes sure to inject quotes and escapes as necessary depending
|
|
|
|
on the content of each string.
|
|
|
|
|
|
|
|
This can also be used to put quotes around the executable of a command.
|
|
|
|
I<This must never ever be done on VMS.>
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
|
|
|
|
sub quotify {
|
|
|
|
# Unix setup (default if nothing else is mentioned)
|
|
|
|
my $arg_formatter =
|
|
|
|
sub { $_ = shift; /\s|[\{\}\\\$\[\]\*\?\|\&:;<>]/ ? "'$_'" : $_ };
|
|
|
|
|
|
|
|
if ( $^O eq "VMS") { # VMS setup
|
|
|
|
$arg_formatter = sub {
|
|
|
|
$_ = shift;
|
|
|
|
if (/\s|["[:upper:]]/) {
|
|
|
|
s/"/""/g;
|
|
|
|
'"'.$_.'"';
|
|
|
|
} else {
|
|
|
|
$_;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
} elsif ( $^O eq "MSWin32") { # MSWin setup
|
|
|
|
$arg_formatter = sub {
|
|
|
|
$_ = shift;
|
|
|
|
if (/\s|["\|\&\*\;<>]/) {
|
|
|
|
s/(["\\])/\\$1/g;
|
|
|
|
'"'.$_.'"';
|
|
|
|
} else {
|
|
|
|
$_;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
return map { $arg_formatter->($_) } @_;
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
######################################################################
|
|
|
|
# private functions. These are never exported.
|
|
|
|
|
|
|
|
=head1 ENVIRONMENT
|
|
|
|
|
|
|
|
OpenSSL::Test depends on some environment variables.
|
|
|
|
|
|
|
|
=over 4
|
|
|
|
|
|
|
|
=item B<TOP>
|
|
|
|
|
|
|
|
This environment variable is mandatory. C<setup> will check that it's
|
|
|
|
defined and that it's a directory that contains the file C<Configure>.
|
|
|
|
If this isn't so, C<setup> will C<BAIL_OUT>.
|
|
|
|
|
|
|
|
=item B<BIN_D>
|
|
|
|
|
|
|
|
If defined, its value should be the directory where the openssl application
|
|
|
|
is located. Defaults to C<$TOP/apps> (adapted to the operating system).
|
|
|
|
|
|
|
|
=item B<TEST_D>
|
|
|
|
|
|
|
|
If defined, its value should be the directory where the test applications
|
|
|
|
are located. Defaults to C<$TOP/test> (adapted to the operating system).
|
|
|
|
|
|
|
|
=item B<STOPTEST>
|
|
|
|
|
|
|
|
If defined, it puts testing in a different mode, where a recipe with
|
|
|
|
failures will result in a C<BAIL_OUT> at the end of its run.
|
|
|
|
|
|
|
|
=back
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
|
|
|
sub __env {
|
2016-01-30 00:05:33 +00:00
|
|
|
$directories{SRCTOP} = $ENV{SRCTOP} || $ENV{TOP};
|
|
|
|
$directories{BLDTOP} = $ENV{BLDTOP} || $ENV{TOP};
|
2016-03-29 17:41:20 +00:00
|
|
|
$directories{BLDAPPS} = $ENV{BIN_D} || __bldtop_dir("apps");
|
|
|
|
$directories{SRCAPPS} = __srctop_dir("apps");
|
|
|
|
$directories{BLDTEST} = $ENV{TEST_D} || __bldtop_dir("test");
|
|
|
|
$directories{SRCTEST} = __srctop_dir("test");
|
|
|
|
$directories{RESULTS} = $ENV{RESULT_D} || $directories{BLDTEST};
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-04-07 12:30:15 +00:00
|
|
|
push @direnv, "TOP" if $ENV{TOP};
|
|
|
|
push @direnv, "SRCTOP" if $ENV{SRCTOP};
|
|
|
|
push @direnv, "BLDTOP" if $ENV{BLDTOP};
|
|
|
|
push @direnv, "BIN_D" if $ENV{BIN_D};
|
|
|
|
push @direnv, "TEST_D" if $ENV{TEST_D};
|
|
|
|
push @direnv, "RESULT_D" if $ENV{RESULT_D};
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
$end_with_bailout = $ENV{STOPTEST} ? 1 : 0;
|
|
|
|
};
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
sub __srctop_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $f = pop;
|
|
|
|
return catfile($directories{SRCTOP},@_,$f);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub __srctop_dir {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
return catdir($directories{SRCTOP},@_);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub __bldtop_file {
|
2015-04-30 12:30:15 +00:00
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $f = pop;
|
2016-01-30 00:05:33 +00:00
|
|
|
return catfile($directories{BLDTOP},@_,$f);
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
sub __bldtop_dir {
|
2015-10-12 20:16:07 +00:00
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
return catdir($directories{BLDTOP},@_);
|
2015-10-12 20:16:07 +00:00
|
|
|
}
|
|
|
|
|
2016-03-31 13:02:02 +00:00
|
|
|
sub __exeext {
|
|
|
|
my $ext = "";
|
|
|
|
if ($^O eq "VMS" ) { # VMS
|
|
|
|
$ext = ".exe";
|
|
|
|
} elsif ($^O eq "MSWin32") { # Windows
|
|
|
|
$ext = ".exe";
|
|
|
|
}
|
|
|
|
return $ENV{"EXE_EXT"} || $ext;
|
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
sub __test_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
2016-03-31 13:02:02 +00:00
|
|
|
my $f = pop . __exeext();
|
2016-03-29 17:41:20 +00:00
|
|
|
$f = catfile($directories{BLDTEST},@_,$f);
|
|
|
|
$f = catfile($directories{SRCTEST},@_,$f) unless -x $f;
|
|
|
|
return $f;
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
sub __perltest_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $f = pop;
|
2016-03-29 17:41:20 +00:00
|
|
|
$f = catfile($directories{BLDTEST},@_,$f);
|
|
|
|
$f = catfile($directories{SRCTEST},@_,$f) unless -f $f;
|
|
|
|
return ($^X, $f);
|
2016-01-26 13:57:21 +00:00
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
sub __apps_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
2016-03-31 13:02:02 +00:00
|
|
|
my $f = pop . __exeext();
|
2016-03-29 17:41:20 +00:00
|
|
|
$f = catfile($directories{BLDAPPS},@_,$f);
|
|
|
|
$f = catfile($directories{SRCAPPS},@_,$f) unless -x $f;
|
|
|
|
return $f;
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
sub __perlapps_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $f = pop;
|
2016-03-29 17:41:20 +00:00
|
|
|
$f = catfile($directories{BLDAPPS},@_,$f);
|
|
|
|
$f = catfile($directories{SRCAPPS},@_,$f) unless -f $f;
|
|
|
|
return ($^X, $f);
|
2016-01-26 13:57:21 +00:00
|
|
|
}
|
|
|
|
|
2015-04-30 12:30:15 +00:00
|
|
|
sub __results_file {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $f = pop;
|
|
|
|
return catfile($directories{RESULTS},@_,$f);
|
|
|
|
}
|
|
|
|
|
|
|
|
sub __cwd {
|
2016-01-14 16:38:52 +00:00
|
|
|
my $dir = catdir(shift);
|
2015-04-30 12:30:15 +00:00
|
|
|
my %opts = @_;
|
|
|
|
my $abscurdir = rel2abs(curdir());
|
|
|
|
my $absdir = rel2abs($dir);
|
|
|
|
my $reverse = abs2rel($abscurdir, $absdir);
|
|
|
|
|
|
|
|
# PARANOIA: if we're not moving anywhere, we do nothing more
|
|
|
|
if ($abscurdir eq $absdir) {
|
|
|
|
return $reverse;
|
|
|
|
}
|
|
|
|
|
|
|
|
# Do not support a move to a different volume for now. Maybe later.
|
|
|
|
BAIL_OUT("FAILURE: \"$dir\" moves to a different volume, not supported")
|
|
|
|
if $reverse eq $abscurdir;
|
|
|
|
|
|
|
|
# If someone happened to give a directory that leads back to the current,
|
|
|
|
# it's extremely silly to do anything more, so just simulate that we did
|
|
|
|
# move.
|
|
|
|
# In this case, we won't even clean it out, for safety's sake.
|
|
|
|
return "." if $reverse eq "";
|
|
|
|
|
|
|
|
$dir = canonpath($dir);
|
|
|
|
if ($opts{create}) {
|
|
|
|
mkpath($dir);
|
|
|
|
}
|
|
|
|
|
|
|
|
# Should we just bail out here as well? I'm unsure.
|
|
|
|
return undef unless chdir($dir);
|
|
|
|
|
|
|
|
if ($opts{cleanup}) {
|
2016-02-08 15:44:48 +00:00
|
|
|
rmtree(".", { safe => 0, keep_root => 1 });
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# For each of these directory variables, figure out where they are relative
|
|
|
|
# to the directory we want to move to if they aren't absolute (if they are,
|
|
|
|
# they don't change!)
|
2016-01-30 00:05:33 +00:00
|
|
|
my @dirtags = sort keys %directories;
|
2015-04-30 12:30:15 +00:00
|
|
|
foreach (@dirtags) {
|
|
|
|
if (!file_name_is_absolute($directories{$_})) {
|
|
|
|
my $newpath = abs2rel(rel2abs($directories{$_}), rel2abs($dir));
|
|
|
|
$directories{$_} = $newpath;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-07 12:30:15 +00:00
|
|
|
# Treat each environment variable that was used to get us the values in
|
|
|
|
# %directories the same was as the paths in %directories, so any sub
|
|
|
|
# process can use their values properly as well
|
|
|
|
foreach (@direnv) {
|
|
|
|
if (!file_name_is_absolute($ENV{$_})) {
|
|
|
|
my $newpath = abs2rel(rel2abs($ENV{$_}), rel2abs($dir));
|
|
|
|
$ENV{$_} = $newpath;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
if ($debug) {
|
2015-04-30 12:30:15 +00:00
|
|
|
print STDERR "DEBUG: __cwd(), directories and files:\n";
|
2016-03-29 17:41:20 +00:00
|
|
|
print STDERR " \$directories{BLDTEST} = \"$directories{BLDTEST}\"\n";
|
|
|
|
print STDERR " \$directories{SRCTEST} = \"$directories{SRCTEST}\"\n";
|
2015-04-30 12:30:15 +00:00
|
|
|
print STDERR " \$directories{RESULTS} = \"$directories{RESULTS}\"\n";
|
2016-03-29 17:41:20 +00:00
|
|
|
print STDERR " \$directories{BLDAPPS} = \"$directories{BLDAPPS}\"\n";
|
|
|
|
print STDERR " \$directories{SRCAPPS} = \"$directories{SRCAPPS}\"\n";
|
2016-01-30 00:05:33 +00:00
|
|
|
print STDERR " \$directories{SRCTOP} = \"$directories{SRCTOP}\"\n";
|
|
|
|
print STDERR " \$directories{BLDTOP} = \"$directories{BLDTOP}\"\n";
|
2015-04-30 12:30:15 +00:00
|
|
|
print STDERR "\n";
|
|
|
|
print STDERR " current directory is \"",curdir(),"\"\n";
|
|
|
|
print STDERR " the way back is \"$reverse\"\n";
|
|
|
|
}
|
|
|
|
|
|
|
|
return $reverse;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub __fixup_cmd {
|
|
|
|
my $prog = shift;
|
2016-01-26 16:50:13 +00:00
|
|
|
my $exe_shell = shift;
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-01-30 00:05:33 +00:00
|
|
|
my $prefix = __bldtop_file("util", "shlib_wrap.sh")." ";
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-01-26 16:50:13 +00:00
|
|
|
if (defined($exe_shell)) {
|
|
|
|
$prefix = "$exe_shell ";
|
2015-10-12 20:16:07 +00:00
|
|
|
} elsif ($^O eq "VMS" ) { # VMS
|
2016-01-30 16:11:48 +00:00
|
|
|
$prefix = ($prog =~ /^(?:[\$a-z0-9_]+:)?[<\[]/i ? "mcr " : "mcr []");
|
2015-04-30 12:30:15 +00:00
|
|
|
} elsif ($^O eq "MSWin32") { # Windows
|
|
|
|
$prefix = "";
|
|
|
|
}
|
|
|
|
|
|
|
|
# We test both with and without extension. The reason
|
2016-01-26 13:57:21 +00:00
|
|
|
# is that we might be passed a complete file spec, with
|
|
|
|
# extension.
|
|
|
|
if ( ! -x $prog ) {
|
2016-03-31 13:02:02 +00:00
|
|
|
my $prog = "$prog";
|
2016-01-26 13:57:21 +00:00
|
|
|
if ( ! -x $prog ) {
|
|
|
|
$prog = undef;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (defined($prog)) {
|
|
|
|
# Make sure to quotify the program file on platforms that may
|
|
|
|
# have spaces or similar in their path name.
|
|
|
|
# To our knowledge, VMS is the exception where quotifying should
|
|
|
|
# never happem.
|
|
|
|
($prog) = quotify($prog) unless $^O eq "VMS";
|
|
|
|
return $prefix.$prog;
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
print STDERR "$prog not found\n";
|
|
|
|
return undef;
|
|
|
|
}
|
|
|
|
|
|
|
|
sub __build_cmd {
|
|
|
|
BAIL_OUT("Must run setup() first") if (! $test_name);
|
|
|
|
|
|
|
|
my $num = shift;
|
|
|
|
my $path_builder = shift;
|
2015-09-03 17:41:40 +00:00
|
|
|
# Make a copy to not destroy the caller's array
|
|
|
|
my @cmdarray = ( @{$_[0]} ); shift;
|
2016-03-29 17:36:55 +00:00
|
|
|
my %opts = @_;
|
2016-01-26 13:57:21 +00:00
|
|
|
|
|
|
|
# We do a little dance, as $path_builder might return a list of
|
|
|
|
# more than one. If so, only the first is to be considered a
|
|
|
|
# program to fix up, the rest is part of the arguments. This
|
|
|
|
# happens for perl scripts, where $path_builder will return
|
2016-01-26 16:50:13 +00:00
|
|
|
# a list of two, $^X and the script name.
|
|
|
|
# Also, if $path_builder returned more than one, we don't apply
|
|
|
|
# the EXE_SHELL environment variable.
|
2016-01-26 13:57:21 +00:00
|
|
|
my @prog = ($path_builder->(shift @cmdarray));
|
2016-01-26 16:50:13 +00:00
|
|
|
my $first = shift @prog;
|
|
|
|
my $exe_shell = @prog ? undef : $ENV{EXE_SHELL};
|
|
|
|
my $cmd = __fixup_cmd($first, $exe_shell);
|
2016-01-26 13:57:21 +00:00
|
|
|
if (@prog) {
|
|
|
|
if ( ! -f $prog[0] ) {
|
|
|
|
print STDERR "$prog[0] not found\n";
|
|
|
|
$cmd = undef;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
my @args = (@prog, @cmdarray);
|
2016-03-29 17:36:55 +00:00
|
|
|
if (defined($opts{interpreter_args})) {
|
|
|
|
unshift @args, @{$opts{interpreter_args}};
|
|
|
|
}
|
2015-04-30 12:30:15 +00:00
|
|
|
|
|
|
|
return () if !$cmd;
|
|
|
|
|
|
|
|
my $arg_str = "";
|
|
|
|
my $null = devnull();
|
|
|
|
|
|
|
|
|
|
|
|
$arg_str = " ".join(" ", quotify @args) if @args;
|
|
|
|
|
|
|
|
my $fileornull = sub { $_[0] ? $_[0] : $null; };
|
|
|
|
my $stdin = "";
|
|
|
|
my $stdout = "";
|
|
|
|
my $stderr = "";
|
|
|
|
my $saved_stderr = undef;
|
|
|
|
$stdin = " < ".$fileornull->($opts{stdin}) if exists($opts{stdin});
|
|
|
|
$stdout= " > ".$fileornull->($opts{stdout}) if exists($opts{stdout});
|
|
|
|
$stderr=" 2> ".$fileornull->($opts{stderr}) if exists($opts{stderr});
|
|
|
|
|
|
|
|
my $display_cmd = "$cmd$arg_str$stdin$stdout$stderr";
|
2016-02-12 17:16:23 +00:00
|
|
|
|
|
|
|
$stderr=" 2> ".$null
|
|
|
|
unless $stderr || !$ENV{HARNESS_ACTIVE} || $ENV{HARNESS_VERBOSE};
|
|
|
|
|
|
|
|
$cmd .= "$arg_str$stdin$stdout$stderr";
|
2015-04-30 12:30:15 +00:00
|
|
|
|
2016-01-26 13:57:21 +00:00
|
|
|
if ($debug) {
|
|
|
|
print STDERR "DEBUG[__build_cmd]: \$cmd = \"$cmd\"\n";
|
|
|
|
print STDERR "DEBUG[__build_cmd]: \$display_cmd = \"$display_cmd\"\n";
|
|
|
|
}
|
|
|
|
|
2016-02-12 17:16:23 +00:00
|
|
|
return ($cmd, $display_cmd);
|
2015-04-30 12:30:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
=head1 SEE ALSO
|
|
|
|
|
|
|
|
L<Test::More>, L<Test::Harness>
|
|
|
|
|
|
|
|
=head1 AUTHORS
|
|
|
|
|
|
|
|
Richard Levitte E<lt>levitte@openssl.orgE<gt> with assitance and
|
|
|
|
inspiration from Andy Polyakov E<lt>appro@openssl.org<gt>.
|
|
|
|
|
|
|
|
=cut
|
|
|
|
|
Groundwork for a perl based testing framework
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>
2015-04-17 17:44:48 +00:00
|
|
|
1;
|