Guidelines for test developers ============================== 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/build.info. Please refer to the section ["Changes to test/build.info"](README.md#changes-to-testbuildinfo) below. Naming conventions ------------------ 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: 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: 60 X509 subsystem 61 BIO subsystem 65 CMP subsystem 70 PACKET layer 80-89 "larger" protocols (CA, CMS, OCSP, SSL, TSA) 90-98 misc 99 most time consuming tests [such as test_fuzz] A recipe that just runs a test executable ----------------------------------------- A script that just runs a program looks like this: #! /usr/bin/env perl use OpenSSL::Test::Simple; 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 `perldoc util/perl/OpenSSL/Test/Simple.pm`. 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 documentation. For OpenSSL::Test, do `perldoc util/perl/OpenSSL/Test.pm`. A script to start from could be this: #! /usr/bin/env perl use strict; use warnings; use OpenSSL::Test; setup("test_{name}"); plan tests => 2; # The number of tests being performed ok(test1, "test1"); ok(test2, "test1"); sub test1 { # test feature 1 } sub test2 { # test feature 2 } Changes to test/build.info -------------------------- 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): * add `{name}` to the list of programs under `PROGRAMS_NO_INST` * 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: SOURCE[{name}]={name}.c INCLUDE[{name}]=.. ../include ../apps/include DEPEND[{name}]=../libcrypto libtestutil.a Generic form of C test executables ---------------------------------- #include "testutil.h" 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_eq(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; } int setup_tests(void) { ADD_TEST(my_test); /* Add each test separately */ return 1; /* Indicate success */ } 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, 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. Note that the test infrastructure automatically sets up all required environment variables (such as `OPENSSL_MODULES`, `OPENSSL_CONF`, etc.) for the tests. Individual tests may choose to override the default settings as required.