A complete unit testing framework in a header

liblittletest

A complete unit testing framework in a header

liblittletest is an easy to use all-in-an-header testing framework; all you have to do in order to use it is to include the header in your code.

How to use

Preparing Tests

Suites

A suite represents a model for tests; it defines set_up and tear_down methods used in all the tests which refer to the suite. All suite attributes are directly usable by its tests.

A suite can be defined in this way:

LT_BEGIN_SUITE(suite_name)
...attributes....
void set_up()
{
    ...
}

void tear_down()
{
    ...
}
LT_END_SUITE(suite_name)

It is possible to define a suite without specifying set_up or tear_down methods. set_up and tear_down methods are called respectively before and after each test.

Running Tests (the manual way)

Tests

A test is an entity containing the used to check your applications. If you plan to run your tests manually you have to initialize your tests this way:

LT_BEGIN_TEST(suite_name, test_name)
    ...
LT_END_TEST(test_name)

As you can see, the suite_name is the first parameter specified and so the test "inherits" set_up and tear_down methods and is able to use each attribute defined inside the suite.

Runners and Environment

Tests are performed by runners. A runner is an object that not only runs tests but also collects all informations about successes and failures and also about timings. Is up to the runner to execute set_up and tear_down methods.

Each runner is specialized to work with tests of a particular suite and it is not possible with a single runner to execute tests of different suites.

A runner can live only inside an environment.

LT_BEGIN_TEST_ENV()
    LT_CREATE_RUNNER(suite_name, runner_name);
    LT_RUNNER(runner_name)(test_1)(test_2)(test_3)();
LT_END_TEST_ENV()

In the previous example a test environment is created and a runner is initialized. The three tests, test_1, test_2 and test_3 are registered and the runner is executed.

Running Tests (the automatic way)

Tests

Sometimes a manual management of tests running is not necessary and only disturbing. If you do not need to manage manually your tests, you can write your tests this way:

LT_BEGIN_AUTO_TEST(suite_name, test_name)
    ...
LT_END_AUTO_TEST(test_name)

The syntax of the macro is the same apart of the "AUTO" prefix.

Runners and Environment

Also in this case, tests are executed by a runner and inside an environment, but it is all easier to do (compared to the previous version). The sole thing you have to do is:

LT_BEGIN_AUTO_TEST_ENV()
    AUTORUN_TESTS()
LT_END_AUTO_TEST_ENV()

Tests Content

Controls

Checks

Checks are simple controls. A failed check represents a failure for the runner and, otherwise, a succeeded check represents a success.

  • LT_CHECK(expr) : the check succeeds if expr returns true;
  • LT_CHECK_EQ(a,b) : the check succeeds if a is equal to b;
  • LT_CHECK_NEQ(a,b) : the check succeeds if a is not equal to b;
  • LT_CHECK_GT(a, b) : the check succeeds if a is greater than b;
  • LT_CHECK_GTE(a, b) : the check succeeds if a is greater or equal to b;
  • LT_CHECK_LT(a, b) : the check succeeds if a is lesser than b;
  • LT_CHECK_LTE(a, b) : the check succeeds if a is lessert or equal to b;
  • LT_CHECK_THROW(expr) : the check succeeds if expr raises an exception;
  • LT_CHECK_NOTHROW(expr) : the check succeeds if expr does not raise an exception;
  • LT_CHECK_COLLECTIONS_EQ(first1, last1, first2) : the check succeeds if collections a and b are equal;
  • LT_CHECK_COLLECTIONS_NEQ(first1, last1, first2) : the check succeeds if collections a and b are not equal;

Warnings

Warnings are used to signal that maybe a problem (but not that the test failed). A failed warn control does not represent a failure for the runner and, for the same reason, a succeeded warn control does not represent a success.

  • LT_WARN(expr) : the check succeeds if expr returns true;
  • LT_WARN_EQ(a,b) : the check succeeds if a is equal to b;
  • LT_WARN_NEQ(a,b) : the check succeeds if a is not equal to b;
  • LT_WARN_GT(a, b) : the check succeeds if a is greater than b;
  • LT_WARN_GTE(a, b) : the check succeeds if a is greater or equal to b;
  • LT_WARN_LT(a, b) : the check succeeds if a is lesser than b;
  • LT_WARN_LTE(a, b) : the check succeeds if a is lessert or equal to b;
  • LT_WARN_THROW(expr) : the check succeeds if expr raises an exception;
  • LT_WARN_NOTHROW(expr) : the check succeeds if expr does not raise an exception;
  • LT_WARN_COLLECTIONS_EQ(first1, last1, first2) : the check succeeds if collections a and b are equal;
  • LT_WARN_COLLECTIONS_NEQ(first1, last1, first2) : the check succeeds if collections a and b are not equal;

Asserts

Asserts are serious controls that need to be satisfied in order to continue a test. When an assert is unattended the test must be interrupted and the next test is executed. A failed assert represents a failure for the runner and, otherwise, a succeeded assert represents a success.

  • LT_ASSERT(expr) : the check succeeds if expr returns true;
  • LT_ASSERT_EQ(a,b) : the check succeeds if a is equal to b;
  • LT_ASSERT_NEQ(a,b) : the check succeeds if a is not equal to b;
  • LT_ASSERT_GT(a, b) : the check succeeds if a is greater than b;
  • LT_ASSERT_GTE(a, b) : the check succeeds if a is greater or equal to b;
  • LT_ASSERT_LT(a, b) : the check succeeds if a is lesser than b;
  • LT_ASSERT_LTE(a, b) : the check succeeds if a is lessert or equal to b;
  • LT_ASSERT_THROW(expr) : the check succeeds if expr raises an exception;
  • LT_ASSERT_NOTHROW(expr) : the check succeeds if expr does not raise an exception;
  • LT_ASSERT_COLLECTIONS_EQ(first1, last1, first2) : the check succeeds if collections a and b are equal;
  • LT_ASSERT_COLLECTIONS_NEQ(first1, last1, first2) : the check succeeds if collections a and b are not equal;

Checkpoints

Sometimes a code may generate uncaught exceptions that the executing runner catches and reports. In these cases may be useful to know which was the last checkpoint the executor passed through.

You can set a checkpoint inside your tests using the macro:

LT_CHECKPOINT()

Piloted Failures

It maybe useful sometimes to generate a failure manually. This is always possible to do this by the use of the macro:

LT_FAIL(message)

This will generate a failure equal to that emitted by a failed assert printing out the specified message.

Owner
Similar Resources

C unit tests with a small header-only library.

C unit tests with a small header-only library.

C unit tests Minimalistic unit tests in C. Uses the __attribute__((constructor)) which, as far as I know, is supported by GCC and clang. So this proba

Aug 28, 2022

Various Framework to do Unit Test in C++

Various Framework to do Unit Test in C++

Unit Test in C++ There are many frameworks to performs unit test in C++, we will present the most popular ones and show how to use them. The testing f

Nov 18, 2021

Header-only C++11 library for property-based testing.

autocheck Header-only C++11 library for QuickCheck (and later, SmallCheck) testing. Please consult the wiki for documentation. Install conan remote ad

Apr 18, 2022

Googletest - Google Testing and Mocking Framework

GoogleTest OSS Builds Status Announcements Release 1.10.x Release 1.10.x is now available. Coming Soon Post 1.10.x googletest will follow Abseil Live

Sep 24, 2022

C++ xUnit-like testing framework without macros

tst C++ testing framework. Installation, documentation, tutorials See WiKi. Features xUnit-like concepts minimal use of preprocessor macros declarativ

Sep 26, 2022

c++ testing framework

iutest iutest - iris unit test framework Welcome to the iutest iutest is framework for writing C++ tests. Features An XUnit test framework. Header onl

Sep 12, 2022

Simple C testing framework

MrTest Simple C testing framework Usage Copy the mrtest.c and mrtest.h file into your project. In order to use the mrtest main: create a .c file that

Jul 20, 2022

xtest is a C++ testing framework inspired by googletest.

xtest is a C++ testing framework inspired by googletest.

xtest C++ testing framework inspired by googletest Explore the docs » Wiki · Report Bug · Request Feature Contents xtest Commence Prerequisites Ubuntu

Jul 9, 2022

A minimal testing framework for C/C++

A minimal testing framework for C/C++

mtest About mtest is a minimal testing framework for C++. Requirements Windows or UNIX-like host A compiler supporting C++11 Usage To include mtest in

Jan 10, 2022
Comments
  • Just 'class'. It's cleaner.

    Just 'class'. It's cleaner.

    All the library uses classes, and access specifiers for both methods/attributes and inheritance are explicit. I don't see any reason for using struct instead of class here.

The C Unit Testing Library on GitHub is a library designed for easy unit testing in C

The C Unit Testing Library on GitHub is a library designed for easy unit testing in C. It was written by Brennan Hurst for the purpose of providing a J-Unit-like testing framework within C for personal projects.

Oct 11, 2021
UT: C++20 μ(micro)/Unit Testing Framework
UT: C++20 μ(micro)/Unit Testing Framework

"If you liked it then you "should have put a"_test on it", Beyonce rule UT / μt | Motivation | Quick Start | Overview | Tutorial | Examples | User Gui

Sep 28, 2022
Modern c++17 unit testing framework on Microsoft Windows, Apple macOS, Linux, iOS and android.
Modern c++17 unit testing framework on Microsoft Windows, Apple macOS, Linux, iOS and android.

tunit Modern c++17 unit testing framework on Windows, macOS, Linux, iOS and android. Continuous Integration build status Operating system Status Windo

Apr 5, 2022
Kernel-mode C++ unit testing framework in BDD-style

There is a lack of unit testing frameworks that work in OS kernel. This library closes that gap and is targeted for windows driver developers.

Jun 11, 2022
A micro unit-testing library for C/C++

µ-test A micro unit testing framework for C/C++ to get you up and running with unit-testing ASAP (even without libc). Usage Simply include the C and h

Dec 8, 2021
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)
A modern, C++-native, header-only, test framework for unit-tests, TDD and BDD - using C++11, C++14, C++17 and later (or C++03 on the Catch1.x branch)

Catch2 v3 is being developed! You are on the devel branch, where the next major version, v3, of Catch2 is being developed. As it is a significant rewo

Sep 26, 2022
A modern, C++11-native, single-file header-only, tiny framework for unit-tests, TDD and BDD (includes C++98 variant)

lest – lest errors escape testing This tiny C++11 test framework is based on ideas and examples by Kevlin Henney [1,2] and on ideas found in the CATCH

Sep 19, 2022
Upp11 - C++11 lightweight single header unit test framework

upp11 Lightweight C++11 single header unit test framework To use framework: Copy upp11.h in you project dir. Create unit test source files or modify e

Apr 4, 2019
The fastest feature-rich C++11/14/17/20 single-header testing framework
The fastest feature-rich C++11/14/17/20 single-header testing framework

master branch Windows All dev branch Windows All doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of

Sep 26, 2022
The fastest feature-rich C++11/14/17/20 single-header testing framework
The fastest feature-rich C++11/14/17/20 single-header testing framework

master branch dev branch doctest is a new C++ testing framework but is by far the fastest both in compile times (by orders of magnitude) and runtime c

Sep 29, 2022