Richard Levitte 5748e4dc3a Fix test/asn1_encode_test.c, ASN1_LONG_DATA used inappropriately
It's sheer luck that this was used for the first field only which also
has the same type in all data structures, so the offsets were never wrong

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3127)
2017-04-05 13:37:37 +02:00
..
2017-03-14 15:18:07 -04:00
2016-03-01 11:59:28 -05:00
2016-11-10 13:04:11 +00:00
2012-12-07 18:47:47 +00:00
2017-03-29 07:14:29 +02:00
2017-03-29 07:14:29 +02:00
2016-05-17 14:20:27 -04:00
2017-03-28 14:40:25 +02:00
2016-05-17 14:20:27 -04:00
2016-08-23 09:24:29 +01:00
2016-11-28 12:26:05 -05:00
2016-06-13 09:18:22 -04:00
2016-05-17 14:20:27 -04:00
2015-11-20 13:40:53 +00:00
2017-03-29 08:51:43 +10:00
2017-03-14 11:44:31 -05:00
2016-06-29 09:56:39 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2017-04-03 23:47:22 +01:00
2017-04-03 23:47:22 +01:00
2016-06-30 08:52:37 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2017-03-29 08:51:43 +10:00
2016-05-17 14:20:27 -04:00
2015-04-20 07:23:04 -04:00
2015-04-20 07:23:04 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2016-05-17 14:20:27 -04:00
2017-03-29 08:51:43 +10:00
2017-04-03 23:47:22 +01:00
2017-03-29 07:14:29 +02:00
2016-07-08 15:56:55 -04:00
2016-05-17 14:20:27 -04:00
2016-11-10 10:12:00 +00:00
2016-10-01 13:46:54 +01:00
2017-03-02 16:49:28 +00:00
2017-04-03 23:47:22 +01:00
2017-04-03 23:47:22 +01:00
2017-04-03 23:47:22 +01:00
2017-03-29 07:14:29 +02:00
2017-03-28 08:43:48 -04:00
2017-03-29 08:51:43 +10:00
2017-03-29 08:51:43 +10:00
2015-04-20 07:23:04 -04:00
2014-12-04 11:55:03 +01:00
2017-03-29 08:51:43 +10:00
2017-03-29 08:51:43 +10:00
2017-01-12 15:23:15 +01:00
2015-09-02 21:22:44 +01:00
2016-06-08 11:37:06 -04:00
2016-05-17 14:20:27 -04:00
2016-09-21 16:19:22 +02: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.


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
   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/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 test/testlib/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 test/testlib/OpenSSL/Test.pm'.

A script to start from could be this:

    #! /usr/bin/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 testutil.c test_main.c
    INCLUDE[{name}]=.. ../include
    DEPEND[{name}]=../libcrypto

Generic form of C test executables
==================================

    #include "test_main.h"
    #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_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;
    }

    void register_tests(void)
    {
        ADD_TEST(my_test);                  /* Add each test separately     */
    }

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.