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 logo

Github Releases Build Status Build Status Code Coverage Try online Join the chat in Discord: https://discord.gg/4CWS9zD

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 rework, you will find that parts of this documentation are likely still stuck on v2.

For stable (and documentation-matching) version of Catch2, go to the v2.x branch.

For migrating from the v2 releases to v3, you should look at our documentation. It provides a simple guidelines on getting started, and collects most common migration problems.

What's the Catch2?

Catch2 is mainly a unit testing framework for C++, but it also provides basic micro-benchmarking features, and simple BDD macros.

Catch2's main advantage is that using it is both simple and natural. Tests autoregister themselves and do not have to be named with valid identifiers, assertions look like normal C++ code, and sections provide a nice way to share set-up and tear-down code in tests.

How to use it

This documentation comprises these three parts:

More

Owner
Catch Org
Organisation account for Catch repositories
Catch Org
Comments
  • CATCH needs a more searchable name

    CATCH needs a more searchable name

    This is not the first time I run into this and I always just shrugged it off before, but after completely failing to find anything about the issue I was interested in (whether anybody has already done something to help with migrating the existing tests using CppUnit to CATCH) I have to say that this is a real problem: it's just impossible to find anything about CATCH using web search.

    It needs to use some unique name or at least not a word so prevalent when speaking about unit testing in C++ (because I'm not interested in finding about how to catch exceptions in CppUnit, damn it).

    It can be anything you like, I don't know if you prefer obvious but dull names (CppCatch, CatchUTF, ...), some other abbreviation (C++ Automated Tests Now Are Possible) or stupid puns (Notry, Dogch, ...) or hopefully something better I can't find, but it needs to be something you could enter into your search engine and actually find something related to CATCH.

  • Never-ending loop wjhen the test case Failed

    Never-ending loop wjhen the test case Failed

    If I use this piece of code:

    #define CATCH_CONFIG_MAIN
    #include "catch.hpp"
    
    #include "TCACAVAUtilities.h"
    
    TEST_CASE( "TCACAVAUtilities::CreateColorFromRGB", "[CreateColorFromRGB]" ) {
        REQUIRE( TCACAVAUtilities::CreateColorFromRGB(0, 0, 0) == 255 );
    }
    

    The result is:

    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\win_b64\code\bin>TCACAVACreateBaseCatalog.exe
    All tests passed (1 assertion in 1 test case)
    

    But If I use this code:

    #define CATCH_CONFIG_MAIN
    #include "catch.hpp"
    
    #include "TCACAVAUtilities.h"
    
    TEST_CASE( "TCACAVAUtilities::CreateColorFromRGB", "[CreateColorFromRGB]" ) {
        REQUIRE( TCACAVAUtilities::CreateColorFromRGB(1, 0, 0) == 255 );
        REQUIRE( TCACAVAUtilities::CreateColorFromRGB(0, 0, 0) == 255 );
    }
    

    The result is:

    -------------------------------------------------------------------------------
    TCACAVAUtilities::CreateColorFromRGB
    -------------------------------------------------------------------------------
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(6)
    ...............................................................................
    
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(7): FAILED:
      REQUIRE( TCACAVAUtilities::CreateColorFromRGB(1, 0, 0) == 255 )
    with expansion:
      0x10000ff == 255
    
    -------------------------------------------------------------------------------
    TCACAVAUtilities::CreateColorFromRGB
    -------------------------------------------------------------------------------
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(6)
    ...............................................................................
    
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(7): FAILED:
      REQUIRE( TCACAVAUtilities::CreateColorFromRGB(1, 0, 0) == 255 )
    with expansion:
      0x10000ff == 255
    
    -------------------------------------------------------------------------------
    TCACAVAUtilities::CreateColorFromRGB
    -------------------------------------------------------------------------------
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(6)
    ...............................................................................
    
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(7): FAILED:
      REQUIRE( TCACAVAUtilities::CreateColorFromRGB(1, 0, 0) == 255 )
    with expansion:
      0x10000ff == 255
    
    -------------------------------------------------------------------------------
    TCACAVAUtilities::CreateColorFromRGB
    -------------------------------------------------------------------------------
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(6)
    ...............................................................................
    
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACAVACreateBaseCatalog.cpp(7): FAILED:
      REQUIRE( TCACAVAUtilities::CreateColorFromRGB(1, 0, 0) == 255 )
    with expansion:
      0x10000ff == 255
    
    -------------------------------------------------------------------------------
    TCACAVAUtilities::CreateColorFromRGB
    -------------------------------------------------------------------------------
    C:\SourceCode\CVS_ROOT\CAVA\develop_clean\TCACAVACatalog\TCACAVACreateBaseCatalo
    g.m\src\TCACforrtl: error (200): program aborting due to control-C event
    Image              PC                Routine            Line        Source
    
    libifcoremd.dll    00000000100BAB14  Unknown               Unknown  Unknown
    libifcoremd.dll    00000000100B46B9  Unknown               Unknown  Unknown
    libifcoremd.dll    00000000100A1017  Unknown               Unknown  Unknown
    libifcoremd.dll    0000000010021BF8  Unknown               Unknown  Unknown
    libifcoremd.dll    000000001002DDC8  Unknown               Unknown  Unknown
    kernel32.dll       00000000774F4803  Unknown               Unknown  Unknown
    kernel32.dll       00000000774B652D  Unknown               Unknown  Unknown
    ntdll.dll          00000000776EC541  Unknown               Unknown  Unknown
    

    The never-ending loop which should I stop with CTRL+C.

    Where is the problem ? Do I something wrong ?

  • Xcode/XCTest Runner Integration

    Xcode/XCTest Runner Integration

    This patch adds support for XCTest integration by inverting the usual Catch behavior; rather than using Catch as the test runner, we dynamically register XCTestCase classes with the Objective-C runtime to allow Xcode's test runner to execute (and report on) Catch-defined test cases.

    To use this implementation, a project need only include "XCTestRunner.mm" in their unit test build -- the +[XCTestCaseCatchRegistry load] method will insert an XCTestRegistryHub instance that automatically registers XCTestCase classes for any Catch test cases defined within the image.

    +load methods by definition will run prior to C++ static initializers in the same image, ensuring that we insert our registry prior to any TestCase instances registering themselves.

    Currently, our granularity is limited to test cases -- we can't report on section execution without first registering the section as a test instance in the XCTestCase, and this would require static access to the list of sections/subsections defined within a TestCase or Section.

    This approach is based on the XCTest registration code I wrote for XSmallTest: https://github.com/landonf/XSmallTest

  • Add Catch::toString support for containers

    Add Catch::toString support for containers

    In order to enhance REQUIRE and CHECK error message when testing standard containers, add overloads of Catch::toString for:

    • std::pair
    • ~~std::deque~~
    • ~~std::list~~
    • ~~std::array (c++11)~~
    • ~~std::forward_list (c++11)~~
    • ~~(more types upcoming)~~
    • any type that has a container api (no need to add support for each container individually)

    Those types were printed as "{?}" (default toString implementation for unsupported class). This was contradictory with the documentation:

    "Most [...] std types are supported out of the box"

    when in fact only string, vector and tupple were supported.

    Detail:

    • Renamed the toStringVector.cpp test file to toStringContainers.cpp and type parametrized the vector tests to run them also for deque and list.
    • ~~The overhead of including all the standard container headers is negligable.~~ => No longer needed, types are treated as containers if they fulfill (some) of the container concept constraints.
    • Types are consider containers if they contain value_type and const_iterator members and have begin and end support (members or ADL findable) returning a const_iterator. const_iterator::operator* must also return a const value_type &
    • Beware that a trying to printing a type fulfilling those requirements but returning invalid iterators will results in undefined behaviour. In such case specialize the Catch::IsContainer trait to contain static const bool value = false in order revert to the default behaviour (printing "{?}").
  • #include <catch2/catch.hpp> vs #include

    #include vs #include "catch.hpp"

    Just wondering: It seems more ideomatic to me to include the library name as part of the include name instead of just using the header file name alone. On the other hand, for a single header library there is of course not a big need/difference for it unless the header name is likely to clash with a different file name.

    So I was wondering whether your preference of

    #include "catch.hpp"
    

    over

    #include <catch2/catch.hpp>
    

    was deliberate or more like "for historic reasons" / "didn't care".

  • Tests sorted according to random index instead of random hash

    Tests sorted according to random index instead of random hash

    Description

    Use a random number instead of a hash to sort the tests.

    Motivation

    In v2.x, test cases with names differing only in the last character are almost always run one after the other. For example, for 4 tests called "a1", "a2", "b1" and "b2", only 8 combinations out of the possible 24 were observed in 1000 runs with different seeds.

  • memory leaks detected by MSVCRT debugging facilities

    memory leaks detected by MSVCRT debugging facilities

    Extra information

    Environment: Windows 10 Compiler: Microsoft (R) Compiler Version 19.11.25547 for x64 (VS2017 15.4.4) Compiler options: -sdl -guard:cf -Zc:inline -Zc:rvalueCast -Zc:referenceBinding -Zc:strictStrings -std:c++latest Version of Catch: Current master git source

    Description

    I've just started with Catch and I created a test project following code as described in the Catch2/docs/tutorial.md. I added the #define CATCH_CONFIG_RUNNER and implemented my own wmain, basically a copy of the default. I also added the _CrtDumpMemoryLeaks() diagnostics in the end of wmain. I get the following output:

    Detected memory leaks!
    Dumping objects ->
    {223} normal block at 0x0000013DA7B8EC30, 16 bytes long.
     Data: < ZQ             > B8 5A 51 F6 F7 7F 00 00 00 00 00 00 00 00 00 00 
    Object dump complete.
    

    Is it possible this could be a false indication of memory allocated by Catch waiting to be released at program exit? If so, is it by design?

    Steps to reproduce

    Compile the source file catch_tutorial.cpp.txt

  • Build error in Visual Studio 2013

    Build error in Visual Studio 2013

    I tried to compile the following program using the single-header of the master branch.

    #define CATCH_CONFIG_MAIN
    #include "catch.hpp"
    

    In Visual Studio 2013 Preview, the first error is:

    catch.hpp(1980): error C2694: 'Catch::StreamBufBase::~StreamBufBase(void)': overriding virtual function has less restrictive exception specification than base class virtual member function 'std::basic_streambuf<char,std::char_traits<char>>::~basic_streambuf(void) throw()'
    1>          H:\petter\catch\single_include\catch.hpp(1980) : see declaration of 'Catch::StreamBufBase::~StreamBufBase'
    1>          C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\streambuf(78) : see declaration of 'std::basic_streambuf<char,std::char_traits<char>>::~basic_streambuf'
    
  • testing getting skipped

    testing getting skipped

    It seems when sections are nested within an iteration, only the first iteration gets run. I do this kind of testing a lot and it would be nice if you could have sections within iterations.

    Ideally I would like to be able to do all the permutations of three or four variables, which is currently not possible. At the moment I find myself repeating code quite a lot with testing, and I'd like to have some more functional tests.

    TEST_CASE( (char*)"Cyclohexane", (char*)"[cyclohexane],[validation]" ) 
        {
            Fluid *CHEX = get_fluid(get_Fluid_index("Cyclohexane"));
            double mm = CHEX->params.molemass;
            validator_element data[] = {
                validator_element("T",300.0,"D",9.4*mm,"P",24.173705*1e6),
                validator_element("T",300.0,"D",9.4*mm,"O",115.28612/mm),
                validator_element("T",300.0,"D",9.4*mm,"C",154.76968/mm),
                validator_element("T",300.0,"D",9.4*mm,"A",1383.3876),
                validator_element("T",500.0,"D",6.5*mm,"P",3.9246630*1e6),
                validator_element("T",500.0,"D",6.5*mm,"O",192.52079/mm),
                validator_element("T",500.0,"D",6.5*mm,"C",255.57110/mm),
                validator_element("T",500.0,"D",6.5*mm,"A",434.13058),
                validator_element("T",500.0,"D",0.7*mm,"P",1.9981172*1e6),
                validator_element("T",500.0,"D",0.7*mm,"O",191.96468/mm),
                validator_element("T",500.0,"D",0.7*mm,"C",235.52304/mm),
                validator_element("T",500.0,"D",0.7*mm,"A",155.34798),
                validator_element("T",600.0,"D",3.5*mm,"P",6.8225506*1e6),  
                validator_element("T",600.0,"D",3.5*mm,"O",232.79249/mm),
                validator_element("T",600.0,"D",3.5*mm,"C",388.55212/mm),
                validator_element("T",600.0,"D",3.5*mm,"A",150.53314),
                validator_element("T",553.6,"D",3.3*mm,"P",4.0805433*1e6),
                validator_element("T",553.6,"D",3.3*mm,"O",224.19580/mm), 
                validator_element("T",553.6,"D",3.3*mm,"C",199224.62/mm), 
                validator_element("T",553.6,"D",3.3*mm,"A",87.913862)
            };
    
            //Now actually construct the vector
            std::vector<validator_element> elements(data, data + sizeof(data) / sizeof(validator_element));     
    
            for (std::vector<validator_element>::iterator it = elements.begin(); it != elements.end(); it++)
            {
                validator_element &el = *it;
                SECTION((char*)"validate")
                {
                    double eos = PropsSI((char*)el.in5.c_str(), (char*)el.in1.c_str(), el.in2, (char*)el.in3.c_str(), el.in4, "Cyclohexane")+1000;
                    double valid = el.in6;
                    CHECK(valid == eos);
                }
            }
        }
    
  • support for multi-threaded test-cases?

    support for multi-threaded test-cases?

    Hey Phil,

    do you have plans for supporting test-cases which internally spawn several threads to check correct behavior under multi-threaded conditions? This is not about executing several test cases in parallel.

    At least the Junit reporter does not support that very well and crashes; the Console reporter doesn't seem to have that issue for the same tests (at the moment) but the absence of any sync'ing mechanisms let me worry about that this could change anytime soon...

    For me it was enough to create a ThreadSafeJunitReporter by deriving from JunitReporter and adding a mutex/lock to the method assertionEnded() just like this:

    class ThreadSafeJunitReporter : public Catch::JunitReporter {
    public:
        ThreadSafeJunitReporter(Catch::ReporterConfig const& _config) :
            Catch::JunitReporter(_config) { }
    
        static std::string getDescription() {
            return "Reports test results in an XML format that looks like Ant's junitreport target.\n"
                "\tThis reporter can be used in a multi-threaded environment";
        }
    
        virtual bool assertionEnded(Catch::AssertionStats const& assertionStats) override {
            std::lock_guard<std::mutex> lock(m_mutex);
            return Catch::JunitReporter::assertionEnded(assertionStats);
        }
    
    private:
        std::mutex m_mutex;
    };
    
    INTERNAL_CATCH_REGISTER_REPORTER("junit-thread-safe", ThreadSafeJunitReporter);
    

    And using the command line option -r junit-thread-safe to get stable test runs again.


    BTW: could you change this impl:

            void ReporterRegistry::registerReporter( std::string const& name, IReporterFactory* factory ) {
                m_factories.insert( std::make_pair( name, factory ) );
            }
    

    into this one:

            void ReporterRegistry::registerReporter( std::string const& name, IReporterFactory* factory ) {
                m_factories[name] = factory;
            }
    

    This would allow someone to replace an existing reporter with an own implementation. The insert() call above just inserts the given factory iff there is no factory with name registered yet. The operator[] call will insert or update m_factories in any case.

  • Logging macros scoped to test case instead of current scope

    Logging macros scoped to test case instead of current scope

    So I'm familiar with the INFO macro for logging. However, these logs get lost once the enclosing scope ends. I'd instead like logs to be scoped to a TEST_CASE or SECTION. I have a logging system (basically a singleton) that I can register logging sinks to. For only catch tests, I override the logger to sink all logs to INFO. My hope was, that for failed test cases, it would dump logs that occurred within its own test case across our whole code base (since they all use this logger). But this doesn't work since it's nested so deep, outside of actual test case scope (but still inside; just not explicitly).

    Is there some way I can make all logs in the code base funnel into Catch? Maybe an INFO_WITHIN_TESTCASE macro could be added or something? It would basically keep a list of all logs created, until the test case or section ends and then it is erased.

    ideas?

  • CMake: Exclude empty header dirs from install

    CMake: Exclude empty header dirs from install

    Description

    Explicitly exclude certain subdirectories from the header-file install(DIRECTORY...) command, so that they don't end up as empty directories in the installed tree.

    GitHub Issues

    Fixes #2457

  • Add C++17 support that

    Add C++17 support that "just works" via vcpkg/package managers

    Description I'd like to use code such as the following in a project that gets Catch2 via vcpkg and have it just work (not require a port overlay or patch to the vcpkg repo):

    inline std::string_view test()
    {
        throw std::runtime_error{"bad"};
    }
    
    TEST_CASE("Log exception")
    {
        REQUIRE(test() == "good");
    }
    

    Additional context I thought this was a vcpkg bug, but they've indicated it's an upstream bug: https://github.com/microsoft/vcpkg/issues/25236

    Similar questions have come up here before, but there isn't a solution yet: #2210 #2046

    I'm hoping we can start by getting agreement between Catch2 and vcpkg on what side the right fix would be here. (I think the starting position is both sides think the problem is on the other side, which probably needs to be resolved first in order to get to a solution.)

  • Segfault on launch when using clang + safe-stack on Alpine

    Segfault on launch when using clang + safe-stack on Alpine

    When compiling a test application linked against Catch2 v3.0.1 using Clang with -fsanitize=safe-stack a SIGSEGV is encountered at program start with the following backtrace:

    * thread #1, name = 'poc', stop reason = signal SIGSEGV: invalid address (fault address: 0xfffffffffffffff8)
      * frame #0: 0x000055555566efaf poc`::__cxx_global_var_init() at main.cpp:0
        frame #1: 0x000055555566f0b9 poc`_GLOBAL__sub_I_main.cpp at main.cpp:0
        frame #2: 0x00007ffff7fc0d8b ld-musl-x86_64.so.1
    

    This occurs irrespective of any tests preset in the test binary and only occurs if the line Catch::Session().run(argc, argv) is present in the test application (irrespective of if it actually runs).

    Removing -fsanitize=safe-stack causes the program to execute correctly. Additionally, adding -fsanitize=safe-stack while compiling Catch2 (so that all code is compiled with the flag) does not affect the presence of the bug. The compile optimization level (e.g. debug vs release) also does not affect the behavior.

    The program also executes correctly when not run on Alpine (tested with Arch Linux) under the same conditions. Perhaps musl vs glibc has an effect?

    Expected behavior

    The program should run correctly without segfaulting when compiled with -fsanitize=safe-stack.

    Reproduction steps

    A minimally reproducible CMake file is provided below:

    cmake_minimum_required(VERSION 3.14...3.23)
    
    project("POC" LANGUAGES CXX)
    
    file(WRITE main.cpp "#include <catch2/catch_session.hpp>
    #include <catch2/catch_test_macros.hpp>
    
    int main(int argc, char** argv) {
        return Catch::Session().run(argc, argv);
    }
    
    TEST_CASE(\"poc\", \"[poc]\"){
        REQUIRE(true);
    }
    ")
    
    add_executable(poc main.cpp)
    
    target_compile_options(poc PRIVATE -fsanitize=safe-stack)
    target_link_libraries(poc PRIVATE -fsanitize=safe-stack)
    
    include(FetchContent)
    
    FetchContent_Declare(Catch2
        GIT_REPOSITORY https://github.com/catchorg/Catch2.git
        GIT_TAG v3.0.1
        GIT_SHALLOW true
    )
    FetchContent_MakeAvailable(Catch2)
    
    target_link_libraries(poc PRIVATE Catch2::Catch2)
    

    The file will obtain and compile Catch2 whilst linking into the main executable poc whilst adding -fsanitize=safe-stack to the main executable's compile flags. When built through CMake on Alpine, the example above should yield a SIGSEGV when the main executable is ran.

    Platform information:

    • OS: Alpine Linux 3.16 or edge.
    • Compiler+version: Clang 13.0.1 or later.
    • Catch version: v3.0.1
  • Runtime detection of catch2

    Runtime detection of catch2

    Description I'm writing a custom assert macro because I want to test cases involving assert(). My objective is this custom assert to behave like a regular assert but when it is running catch2 I want it to throw an exception. Some assert are expensive test, so I don't want to turn them into exception, as that would slow regular execution.

    Is this currently possible to detect catch2 at runtime ?

    Additional context Something like that

    #ifndef NDEBUG
        #define my_assert(e) ((void)(static_cast<bool>(e) ? 0 : pivot_assert_failed(#e, __FILE__, __LINE__)))
        #define my_assert_failed(expr, file, line) { if (/* CATCH2 */) throw assertion_failed_exception(); else std::abort(); }
    #else
        #define my_assert(e) 0;
    #endif
    
    
  • Generator::currentElementAsString breaks compilation of a lot of our tests

    Generator::currentElementAsString breaks compilation of a lot of our tests

    In 48f3226974, a new method currentElementAsString was added to generators. As far as I can tell, it isn't used for anything.

    The problem is that this breaks compilation of a lot of our tests, with no obvious workaround. The reason is that we define CATCH_CONFIG_FALLBACK_STRINGIFIER to a non-existing symbol in order to catch mistakes where failing CHECKs wouldn't stringify correctly. This is very useful, and actually I think it should be the default.

    But this now causes compilation failures for GENERATE statements where the type that's generated isn't stringifiable.

    To illustrate, here's a common pattern that we tend to use a lot in our tests:

    using T = std::tuple<InputType1, InputType2, SomeHelper, ExpectedOutput1, ExpectedOutput2>;
    const auto [input1, input2, helper, expectedOutput1, expectedOutput2] = GENERATE(values<T>({
      { ... },
    }));
    
    CAPTURE(input1, input2);
    
    // ...
    

    In this example, InputType1 and InputType2 are stringifiable, and have to be because of the CAPTURE. SomeHelper might, for example, be a std::function. ExpectedOutput1 and ExpectedOutput2 only need to be stringifiable if they appear in a CHECK statement, which they often do, but don't necessarily have to.

    I'd appreciate advice how to work around this. I suppose I could subclass FixedValuesGenerator with an overwritten stringifyImpl method (which would only assert(false)?), but this seems like a lot of work.

    For now we revert 48f3226974 locally, but this is not a satisfactory long-term solution either, of course.

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
C++ Unit Testing Easier: A Header-only C++ unit testing framework

CUTE C++ Unit Testing Easier: A Header-only C++ unit testing framework usually available as part of the Cevelop C++ IDE (http://cevelop.com) Dependenc

Nov 9, 2021
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

May 10, 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
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
TestFrame - This is a test framework that uses Raylib and ImGui together to help test and develop concepts
TestFrame - This is a test framework that uses Raylib and ImGui together to help test and develop concepts

This is a test framework that uses Raylib and ImGui together to help test and develop concepts. It is made using C++ because it uses classes for windows and views.

May 13, 2022
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
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
A dynamic mock tool for C/C++ unit test on Linux&MacOS X86_64

lmock 接口 替换一个函数,修改机器指令,用新函数替换旧函数,支持全局函数(包括第三方和系统函数)、成员函数(包括静态和虚函数)

Jun 13, 2022
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

Nov 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

Jun 13, 2022
Harbour DB speed tests comparison

hbDBSpeedTests Harbour DB speed tests comparison - Registers Count: 821051 MySql configuration( 1 or 2 ) /data/mysql/dbstru.zip - Import structure of

Nov 18, 2021
End to end test framework designed for Juce applications

JUCE End to End test framework What is it? This package provides a mechanism to end-to-end test a JUCE application Prerequisites CMake. Must be 3.18 o

May 29, 2022
Handy C++ test framework

C++ Voyager Test Framework Voyager is a simple and handy C++ Unit Test framework. It is designed to be beautiful and expressive both. Try it to feel i

Mar 16, 2022
Header only C++14 mocking framework
Header only C++14 mocking framework

Trompeloeil Get: trompe l'oeil noun (Concise Encyclopedia) Style of representation in which a painted object is intended to deceive the viewer into be

Jun 20, 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
📝 One of the difficult unit tester for ft_containers project
📝 One of the difficult unit tester for ft_containers project

ft_containers-unit-test About ft containers unit test is a complete testing for project of school 21/ecole 42 and allowing you test your containers: V

Jun 15, 2022
An area to test reading in ATLAS xAOD format and writing out to Parquet

xaod_to_parquet An area to test reading in ATLAS xAOD format and writing out to Parquet Getting the Code Clone the repository with the --recursive fla

Nov 19, 2021
PlatformIO + BL602 Bouffalo Arduino Core Test
 PlatformIO + BL602 Bouffalo Arduino Core Test

PlatformIO + BL602 Bouffalo Arduino Core Test Description Uses A custom extension of the PlatformIO SiFive Platform (https://github.com/maxgerhardt/pl

May 31, 2022