2015-09-03 18:00:28 +08:00
|
|
|
How to add recipes
|
|
|
|
==================
|
|
|
|
|
|
|
|
For any test that you want to perform, you write a script located in
|
|
|
|
test/recipes/, named {nn}-test_{name}.t, where {nn} is a two digit number and
|
|
|
|
{name} is a unique name of your choice.
|
|
|
|
|
|
|
|
Please note that if a test involves a new testing executable, you will need to
|
|
|
|
do some additions in test/Makefile. More on this later.
|
|
|
|
|
|
|
|
|
2016-08-12 06:29:27 +08:00
|
|
|
Naming conventions
|
2015-09-03 18:00:28 +08:00
|
|
|
=================
|
|
|
|
|
|
|
|
A test executable is named test/{name}test.c
|
|
|
|
|
|
|
|
A test recipe is named test/recipes/{nn}-test_{name}.t, where {nn} is a two
|
|
|
|
digit number and {name} is a unique name of your choice.
|
|
|
|
|
|
|
|
The number {nn} is (somewhat loosely) grouped as follows:
|
|
|
|
|
2017-02-17 04:06:42 +08:00
|
|
|
00-04 sanity, internal and essential API tests
|
|
|
|
05-09 individual symmetric cipher algorithms
|
|
|
|
10-14 math (bignum)
|
|
|
|
15-19 individual asymmetric cipher algorithms
|
|
|
|
20-24 openssl commands (some otherwise not tested)
|
|
|
|
25-29 certificate forms, generation and verification
|
|
|
|
30-35 engine and evp
|
|
|
|
60-79 APIs
|
|
|
|
70 PACKET layer
|
|
|
|
80-89 "larger" protocols (CA, CMS, OCSP, SSL, TSA)
|
2017-02-17 17:49:04 +08:00
|
|
|
90-98 misc
|
|
|
|
99 most time consuming tests [such as test_fuzz]
|
2015-09-03 18:00:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
A recipe that just runs a test executable
|
|
|
|
=========================================
|
|
|
|
|
|
|
|
A script that just runs a program looks like this:
|
|
|
|
|
|
|
|
#! /usr/bin/perl
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
use OpenSSL::Test::Simple;
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
simple_test("test_{name}", "{name}test", "{name}");
|
|
|
|
|
|
|
|
{name} is the unique name you have chosen for your test.
|
|
|
|
|
|
|
|
The second argument to `simple_test' is the test executable, and `simple_test'
|
|
|
|
expects it to be located in test/
|
|
|
|
|
|
|
|
For documentation on OpenSSL::Test::Simple, do
|
2017-09-08 06:41:52 +08:00
|
|
|
`perldoc util/perl/OpenSSL/Test/Simple.pm'.
|
2015-09-03 18:00:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
A recipe that runs a more complex test
|
|
|
|
======================================
|
|
|
|
|
|
|
|
For more complex tests, you will need to read up on Test::More and
|
|
|
|
OpenSSL::Test. Test::More is normally preinstalled, do `man Test::More' for
|
2017-09-08 06:41:52 +08:00
|
|
|
documentation. For OpenSSL::Test, do `perldoc util/perl/OpenSSL/Test.pm'.
|
2015-09-03 18:00:28 +08:00
|
|
|
|
|
|
|
A script to start from could be this:
|
|
|
|
|
|
|
|
#! /usr/bin/perl
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
use strict;
|
|
|
|
use warnings;
|
|
|
|
use OpenSSL::Test;
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
setup("test_{name}");
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
plan tests => 2; # The number of tests being performed
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
ok(test1, "test1");
|
|
|
|
ok(test2, "test1");
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
sub test1
|
|
|
|
{
|
|
|
|
# test feature 1
|
|
|
|
}
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
sub test2
|
|
|
|
{
|
|
|
|
# test feature 2
|
|
|
|
}
|
2017-07-13 05:37:01 +08:00
|
|
|
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
Changes to test/build.info
|
|
|
|
==========================
|
2015-09-03 18:00:28 +08:00
|
|
|
|
|
|
|
Whenever a new test involves a new test executable you need to do the
|
|
|
|
following (at all times, replace {NAME} and {name} with the name of your
|
|
|
|
test):
|
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
* add {name} to the list of programs under PROGRAMS_NO_INST
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
* create a three line description of how to build the test, you will have
|
|
|
|
to modify the include paths and source files if you don't want to use the
|
|
|
|
basic test framework:
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-04-18 22:27:27 +08:00
|
|
|
SOURCE[{name}]={name}.c
|
2017-03-22 12:27:55 +08:00
|
|
|
INCLUDE[{name}]=.. ../include
|
2017-04-18 22:27:27 +08:00
|
|
|
DEPEND[{name}]=../libcrypto libtestutil.a
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
Generic form of C test executables
|
|
|
|
==================================
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
#include "testutil.h"
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
static int my_test(void)
|
|
|
|
{
|
|
|
|
int testresult = 0; /* Assume the test will fail */
|
|
|
|
int observed;
|
|
|
|
|
|
|
|
observed = function(); /* Call the code under test */
|
|
|
|
if (!TEST_int_equal(observed, 2)) /* Check the result is correct */
|
|
|
|
goto end; /* Exit on failure - optional */
|
|
|
|
|
|
|
|
testresult = 1; /* Mark the test case a success */
|
|
|
|
end:
|
|
|
|
cleanup(); /* Any cleanup you require */
|
|
|
|
return testresult;
|
|
|
|
}
|
|
|
|
|
2017-07-18 09:48:27 +08:00
|
|
|
int setup_tests(void)
|
2017-03-22 12:27:55 +08:00
|
|
|
{
|
|
|
|
ADD_TEST(my_test); /* Add each test separately */
|
2017-07-18 09:48:27 +08:00
|
|
|
return 1; /* Indicate success */
|
2017-03-22 12:27:55 +08:00
|
|
|
}
|
2015-09-03 18:00:28 +08:00
|
|
|
|
2017-03-22 12:27:55 +08:00
|
|
|
You should use the TEST_xxx macros provided by testutil.h to test all failure
|
|
|
|
conditions. These macros produce an error message in a standard format if the
|
|
|
|
condition is not met (and nothing if the condition is met). Additional
|
|
|
|
information can be presented with the TEST_info macro that takes a printf
|
|
|
|
format string and arguments. TEST_error is useful for complicated conditions,
|
2017-04-13 06:51:28 +08:00
|
|
|
it also takes a printf format string and argument. In all cases the TEST_xxx
|
|
|
|
macros are guaranteed to evaluate their arguments exactly once. This means
|
|
|
|
that expressions with side effects are allowed as parameters. Thus,
|
|
|
|
|
|
|
|
if (!TEST_ptr(ptr = OPENSSL_malloc(..)))
|
|
|
|
|
|
|
|
works fine and can be used in place of:
|
|
|
|
|
|
|
|
ptr = OPENSSL_malloc(..);
|
|
|
|
if (!TEST_ptr(ptr))
|
|
|
|
|
|
|
|
The former produces a more meaningful message on failure than the latter.
|
|
|
|
|