Acutest Readme

Home: http://github.com/mity/acutest

What Is Acutest

"Acutest" means "Another C Unit Testing" and it is intended to do exactly that, while being as simple as possible to use it, not to stand in the developer's way and minimize any external dependencies.

To achieve that, the complete implementation resides in a single C header file, and its core depends only on few standard C library functions.

Acutest supports C as well as C++, and it can deal with unit tests which throw C++ exceptions.

Overview

Main features:

• Unit tests in C or C++ are supported.
• No need to install/setup/configure testing framework. Acutest is just single C/C++ header, "acutest.h".
• The header provides program entry point (function main()).
• Minimal dependencies: Core features only depend on few standard C headers, optional features may use more if available on the particular system.
• Trivial interface for writing unit tests: Few preprocessor macros described further below.
• Rudimentary support for Test Anything Protocol (use --tap option).
• Rudimentary support for xUnit-compatible XML output (use --xml-output=FILE).

Windows specific features:

• By default, every unit test is executed as a child process.
• By default, if the output is directed to a terminal, the output is colorized.
• Acutest installs a SEH filter to print out uncaught SEH exceptions.

Unix specific features:

• By default, every unit test is executed as a child process.
• By default, if the output is directed to a terminal, the output is colorized.

C++ specific features:

• Acutest catches C++ exceptions thrown from unit test functions. Such unit tests are considered to fail.
• If the exception is derived from std::exception, what() is written out in the error message.

Any C/C++ module implementing one or more unit tests and including "acutest.h", can be built as a standalone program. We call the resulted binary as a "test suite" for purposes of this document. The suite is then executed to run the tests, as specified with its command line options.

By default, all unit tests in the program are run and (on Windows and Unix) every unit test is executed in a context of its own subprocess. Both can be overridden on the command line.

We say any unit test succeeds if all conditions (preprocessor macros TEST_CHECK or TEST_CHECK_) called throughout its execution pass, the test does not throw an exception (C++ only), and (on Windows/Unix) the unit test subprocess is not interrupted/terminated (e.g. by a signal on Unix or SEH on Windows).

Exit code of the test suite is 0 if all unit tests pass, 1 if any of them fails, or other number if an internal error occurs.

Writing Unit Tests

Basic Use

To use Acutest, simply include the header file "acutest.h" on the beginning of the C/C++ source file implementing one or more unit tests. Note the header provides implementation of the main() function.

#include "acutest.h"

Every test is supposed to be implemented as a function with the following prototype:

void test_example(void);

The tests can use some preprocessor macros to validate the test conditions. They can be used multiple times, and if any of those conditions fails, the particular test is considered to fail.

TEST_CHECK is the most commonly used testing macros which simply test a boolean condition and fail if the condition evaluates to false (or zero).

For example:

void test_example(void)
{
    void* mem;
    int a, b;

    mem = malloc(10);
    TEST_CHECK(mem != NULL);

    mem = realloc(mem, 20);
    TEST_CHECK(mem != NULL);
}

Note that the tests should be independent on each other. Whenever the test suite is invoked, the user may run any number of tests in the suite, in any order. Furthermore by default, on platforms where supported, each unit test is executed as a standalone (sub)process.

Finally, the test suite source file has to list the unit tests, using the macro TEST_LIST. The list specifies name of each test (it has to be unique) and pointer to a function implementing the test. I recommend names which are easy to use on command line, i.e. especially avoid space and other special characters in them. Also avoid using dash as a first character, as it would be then interpreted as a command line option, not a test name.

TEST_LIST = {
   { "example", test_example },
   ...
   { 0 }
};

Note the test list has to be ended with zeroed record.

For a basic test suites this is more or less all you need to know. However Acutest provides some more macros which can be useful in some specific situations. We cover them in the following sub-sections.

Testing C++ Exceptions

For C++, there is an additional macro TEST_EXCEPTION for verifying the given code (typically just a function or a method call) throw the expected type of exception. The check fails if the function does not throw any exception or if it throws anything incompatible.

For example:

void test_example(void)
{
    TEST_EXCEPTION(CallSomeFunction(), std::exception);
}

Richer Failure Diagnosis

If a condition check fails, it is often useful to provide some additional information about the situation so the problem is easier to debug. Acutest provides the macros TEST_MSG and TEST_DUMP for this purpose.

The former one outputs any printf-like message, the other one outputs a hexadecimal dump of a provided memory block.

Note that both macros only output anything in the most recently checking macro failed.

So for example:

void test_example(void)
{
    char produced[100];
    char expected[] = "Hello World!";

    SomeSprintfLikeFunction(expected, "Hello %s!", world);
    TEST_CHECK(strlen(produced) == strlen(expected));
    TEST_MESSAGE("Expected: %s", expected);
    TEST_MESSAGE("Produced: %s", produced);

    /* Or if the function would provide some binary stuff, we might rather
     * use TEST_DUMP instead and output a hexadecimal dump. */
    TEST_DUMP("Expected:", expected, strlen(expected));
    TEST_DUMP("Produced:", produced, strlen(produced));
}

(Note that TEST_MSG requires the compiler with variadic macros support.)

Test Vectors

Sometimes, it is useful to construct the testing function as a loop over some data verifying that for some input vector we get always the expected output vector. For example we are verifying some kind of hashing function and some specification provides a set of test vectors for it.

In such cases, it is convenient to output a message what iteration we are checking so that, if any check fails, we can easily in the output log for which input vector it has happened.

Acutest provides the macro TEST_CASE for this purpose.

For example, assuming we are testing SomeFunction() which, for a given byte array of some size returns another array of bytes (in a newly malloc-ed buffer), we could something like this:

struct TestVector {
    const char* name;
    const uint8_t* input;
    size_t input_size;
    const uint8_t* expected_output;
    size_t expected_output_size;
};

struct TestVector test_vectors[] = {
    /* some data */
};

void test_example(void)
{
    int i;
    const uint8_t* output;
    size_t output_size;

    for(i = 0; i < sizeof(test_vectors) / sizeof(test_vectors[0]); i++) {
        struct TestVector* vec = &test_vectors[i];

        TEST_CASE(vec.name);

        output = SomeFunction(vec->input, vec->input_size, &output_size);
        if(TEST_CHECK(output != NULL)) {
            TEST_CHECK(output_size == vec->expected_output_size);
            TEST_CHECK(memcmp(output, vec->expected_output, output_size) == 0);
            free(output);
        }
    }

    /* Reset the iteration name.
     *
     * This is actually only needed if our tests does some more checks after
     * the loop above. */
    TEST_CASE(NULL);
}

Custom Log Messages

Many of the macros mentioned in the earlier sections have a variant which allows to output a custom messages instead of some default ones.

All of these have the same name as the aforementioned macros with the additional underscore suffix and they also expect printf-like string format (and corresponding additional arguments).

So for example instead of

TEST_CHECK(a == b);
TEST_EXCEPTION(SomeFunction(), std::exception);

we can use

TEST_CHECK_(a == b, "%d is equal to %d", a, b);
TEST_EXCEPTION_(SomeFunction(), std::exception, "SomeFunction() throws std::exception");

Similarly instead instead of

TEST_CASE("name");

we can use richer

TEST_CASE_("iteration #%d", 42);

However note all of these can only be used if your compiler supports variadic macros.

Building the Test Suite

When we are done with implementing the tests, we can simply compile it as a simple C/C++ program. For example, assuming cc is your C compiler:

$ cc test_example.c -o test_example

Running Unit Tests

When the test suite is compiled, the resulted testing binary can be used to run the tests.

By default (without any command line options), it runs all implemented unit tests. It can also run only subset of the unit tests as specified on the command line:

$ ./test_example                # Runs all tests in the suite
$ ./test_example test1 test2    # Runs only tests specified
$ ./test_example --skip test3   # Runs all tests but those specified

Actually, the command line argument can select more then just one test unit. Acutest implements several levels of unit test selection:

1. Exact match: When the argument matches exactly the whole name of some unit test then just the given test is selected.

2. Word match: When the argument does not match any complete test name, but it does match whole word in one or more test names, then all such tests are selected. (Note that space , tabulator \t, dash - and underscore _ are seen as word delimiters in test names.)

3. Substring match: If even the word match failed to select any test, then all tests with a name which contains the argument as its substring are selected.

By adopting an appropriate test naming strategy, this allows user to run (or to skip if --skip is used) whole group of related tests with a single command line argument.

For example consider test suite test_example which implements tests foo-1, foo-2, foomatic, bar-1 and bar-10:

$ ./test_example bar-1   # Runs only the test 'bar-1' (exact match)
$ ./test_example foo     # Runs 'foo-1' and 'foo-2' (word match)
$ ./test_example oo      # Runs 'foo-1', 'foo-2' and 'foomatic' (substring match)
$ ./test_example 1       # Runs 'foo-1' and 'bar-1' (word match)

You may use --list or -l to just list all unit tests implemented by the given test suite:

$ ./test_example --list

To see description for all the supported command line options, run the binary with the option --help:

$ ./test_example --help

FAQ

Q: Wasn't this project known as "CUTest"?

A: Yes. It has been renamed as the original name was found to be too much overloaded.

Q: Do I need to distribute file README.md and/or LICENSE.md?

A: No. The header acutest.h includes URL to our repo, copyright note and the MIT license terms inside of it. So as long as you leave those intact, we are completely fine if you only add the header into your project. After all, the all-in-one-header is the purpose of it.

License

Acutest is covered with MIT license, see the file LICENSE.md or beginning of "acutest.h" for its full text.

More Information

The project resides on github:

• http://github.com/mity/acutest

You can find the latest version of Acutest there, contribute with enhancements or report bugs.