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 compared to other feature-rich alternatives. It brings the ability of compiled languages such as D / Rust / Nim to have tests written directly in the production code thanks to a fast, transparent and flexible test runner with a clean interface.

Standard License download CII Best Practices Language grade: C/C++ Chat - Discord Try it online

The framework is and will stay free but needs your support to sustain its development. There are lots of new features and maintenance to do. If you work for a company using doctest or have the means to do so, please consider financial support. Monthly donations via Patreon and one-offs via PayPal.

A complete example with a self-registering test that compiles to an executable looks like this:

cover-example

There are many C++ testing frameworks - Catch, Boost.Test, UnitTest++, cpputest, googletest and others.

The key differences between it and other testing frameworks are that it is light and unintrusive:

  • Ultra light on compile times both in terms of including the header and writing thousands of asserts
  • Doesn't produce any warnings even on the most aggressive warning levels for MSVC/GCC/Clang
  • Can remove everything testing-related from the binary with the DOCTEST_CONFIG_DISABLE identifier
  • thread-safe - asserts can be used from multiple threads spawned from a single test case - example
  • asserts can be used outside of a testing context - as a general purpose assert library - example
  • No global namespace pollution (everything is in doctest::) & doesn't drag any headers with it
  • Portable C++11 (use tag 1.2.9 for C++98) with over 100 different CI builds (static analysis, sanitizers..)
  • binaries (exe/dll) can use the test runner of another binary => tests in a single registry - example

cost-of-including-the-framework-header

This allows the framework to be used in more ways than any other - tests can be written directly in the production code!

Tests can be a form of documentation and should be able to reside near the production code which they test.

  • This makes the barrier for writing tests much lower - you don't have to: 1) make a separate source file 2) include a bunch of stuff in it 3) add it to the build system and 4) add it to source control - You can just write the tests for a class or a piece of functionality at the bottom of its source file - or even header file!
  • Tests in the production code can be thought of as documentation/up-to-date comments - showcasing the APIs
  • Testing internals that are not exposed through the public API and headers is no longer a mind-bending exercise
  • Test-driven development in C++ has never been easier!

The framework can be used just like any other without mixing production code and tests - check out the features.

doctest is modeled after Catch and some parts of the code have been taken directly - check out the differences.

This table compares doctest / Catch / lest which are all very similar.

Checkout the CppCon 2017 talk on YouTube to get a better understanding of how the framework works and read about how to use it in the JetBrains article - highlighting the unique aspects of the framework! On a short description on how to use the framework along production code you could refer to this GitHub issue. There is also an older article in the february edition of ACCU Overload 2017.

CppCon 2017 talk about doctest on youtube

Documentation

Project:

Usage:

Contributing

Support the development of the project with donations! There is a list of planned features which are all important and big - see the roadmap. I took a break from working in the industry to make open source software so every cent is a big deal.

If you work for a company using doctest or have the means to do so, please consider financial support.

Contributions in the form of issues and pull requests are welcome as well - check out the Contributing page.

Logo

The logo is licensed under a Creative Commons Attribution 4.0 International License. Copyright © 2019 area55git   License: CC BY 4.0

Owner
The fastest feature-rich C++11/14/17/20 single-header testing framework
null
Comments
  • Add Github Actions CI

    Add Github Actions CI

    Opening the pull request so I can start testing the configuration. I've started by taking reproc's Github Actions configuration and removing everything reproc related. Once that works I'll start adding all doctest related configuration.

  • Regression between 2.4.6 and 2.4.7

    Regression between 2.4.6 and 2.4.7

    Description

    Following minimized code works perfectly on 2.4.6, but fails on 2.4.7

    // #define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN shouldn't be defined in compilation unit to reproduce
    #include <doctest/doctest.h>
    
    #include <string>
    
    namespace {
    
    class B
    {
    public:
        const std::string& getName() const
        {
            return m_name;
        }
    
        std::string m_name = "B";
    };
    
    }  // namespace
    
    TEST_CASE("Wtf?") {
        B b;
    
        CHECK(b.getName() == "B");
    }
    

    https://godbolt.org/z/Eq48fjsed (due to the godbolt limitations see "undefined reference to `main'" linker warnings as success)

    Flags: "-std=c++11 -Wall -Wextra -Wpedantic -Werror"

    It fails on GCC version 4.9 - 10.3 with -fpermissive warning. (GCC version 11.2 compiles it without a problem though 🤔)

    doctest/doctest.h: In instantiation of 'void doctest::detail::fillstream(const T (&)[N]) [with T = char; long unsigned int N = 2]':
    doctest/doctest.h:904:31:   required from 'static void doctest::detail::filldata<T [N]>::fill(const T (&)[N]) [with T = const char; long unsigned int N = 2]'
    doctest/doctest.h:918:65:   required from 'void doctest::detail::filloss(const T (&)[N]) [with T = char; long unsigned int N = 2]'
    doctest/doctest.h:933:20:   required from 'static doctest::String doctest::detail::StringMakerBase<true>::convert(const T&) [with T = char [2]]'
    doctest/doctest.h:978:35:   required from 'doctest::String doctest::toString(const T&) [with T = char [2]; typename doctest::detail::enable_if<(! doctest::detail::is_enum<T>::value), bool>::type <anonymous> = true]'
    doctest/doctest.h:1142:45:   required from 'doctest::String doctest::detail::stringifyBinaryExpr(const L&, const char*, const R&) [with L = std::__cxx11::basic_string<char>; R = char [2]]'
    doctest/doctest.h:1320:9:   required from 'decltype (((void)((declval<L>() == declval<R>())), (doctest::detail::Result)(<brace-enclosed initializer list>()))) doctest::detail::Expression_lhs<L>::operator==(const R&) [with R = char [2]; typename doctest::detail::enable_if<(! doctest::detail::is_rvalue_reference<R>::value), void>::type* <anonymous> = 0; L = const std::__cxx11::basic_string<char>&; decltype (((void)((declval<L>() == declval<R>())), (doctest::detail::Result)(<brace-enclosed initializer list>()))) = doctest::detail::Result]'
    <source>:24:5:   required from here
    doctest/doctest.h:896:31: error: no match for 'operator<<' (operand types are 'std::ostream' {aka 'std::basic_ostream<char, std::char_traits<char> >'} and 'const char')
    doctest/doctest.h:557:33: note: candidate: 'std::ostream& doctest::operator<<(std::ostream&, const doctest::String&)' (near match)
    doctest/doctest.h:557:33: note:   conversion of argument 2 would be ill-formed:
    doctest/doctest.h:896:36: error: invalid user-defined conversion from 'const char' to 'const doctest::String&' [-fpermissive]
    doctest/doctest.h:519:5: note: candidate is: 'doctest::String::String(const char*)' (near match)
    doctest/doctest.h:519:5: note:   conversion of argument 1 would be ill-formed:
    doctest/doctest.h:896:36: error: invalid conversion from 'char' to 'const char*' [-fpermissive]
    doctest/doctest.h:896:36: error: invalid conversion from 'char' to 'const char*' [-fpermissive]
    doctest/doctest.h:519:24: note:   initializing argument 1 of 'doctest::String::String(const char*)'
    In file included from /opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/string:55,
                     from <source>:4:
    /opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/basic_string.h:6468:5: note: candidate: 'template<class _CharT, class _Traits, class _Alloc> std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)'
     6468 |     operator<<(basic_ostream<_CharT, _Traits>& __os,
          |     ^~~~~~~~
    /opt/compiler-explorer/gcc-10.3.0/include/c++/10.3.0/bits/basic_string.h:6468:5: note:   template argument deduction/substitution failed:
    doctest/doctest.h:896:31: note:   mismatched types 'const std::__cxx11::basic_string<_CharT, _Traits, _Alloc>' and 'const char'
    

    It fails on any version of clang, but with an error instead of the warning. It fails on MSVC at least in version 19 that is accessible on Godbolt.

    Using this code as a test, it's possible to bisect a broken commit.

  • Tests inside a static library

    Tests inside a static library

    Hi,

    (This is more a question than an issue) What is the recommended way to add tests inside a static library project ?

    If I compile a library (which includes TEST_CASE(s)) as a static library, and then I try to run the tests from this library by creating a target that links to it, the test suite is actually empty (i.e I guess the tests were stripped at link time)

    Am I doing something wrong, or is there a way to circumvent this?

    Below is an example of what I am trying to achieve (using cmake):

    Project         <- main project
      CMakeLists.txt
      doctest/
        doctest.h
        doctest_main.cpp
      MyLibrary/
        lib1.cpp    <- these files includes actual library code and TEST_CASE(s)
        lib2.cpp    
        lib3.cpp    
        CMakeLists.txt <- will produce two targets : library and its test
      MyMainProgram/
        main.cpp
        CMakeLists.txt
    
    

    MyLibrary/CMakeLists.txt :

        set(sources lib1.cpp lib2.cpp lib3.cpp)
        add_library(MyLibrary STATIC ${sources})
        target_include_directories(MyLibrary PUBLIC ${CMAKE_SOURCE_DIR}/doctest )
    
        # This does not work : it links but the test list is empty !
        add_executable(MyLibrary_DocTest ${CMAKE_SOURCE_DIR}/doctest/doctest_main.cpp)
        target_link_libraries(MyLibrary_DocTest MyLibrary)
    
        # This works, but it requires to re-compile all the source files and to re-define
        # exactly the same compile options as for the library (linked library, compile definition, etc); 
        # this can be tedious
        add_executable(MyLibrary_DocTest ${sources} ${CMAKE_SOURCE_DIR}/doctest/doctest_main.cpp)
    
    

    MyMainProgram/CMakeLists.txt :

        add_executable(MyMainProgram main.cpp)
        target_link_libraries(MyMainProgram MyLibrary)
    

    A working example can be found at https://github.com/pthom/DocTest_LibTest

  • Count points based on the number of passed/failed cases?

    Count points based on the number of passed/failed cases?

    Hi guys, I am now trying to use doctest to grade c++ code assignments, and this is my first time to use doctest. Just one question, is there any way that I can count the points based on how many testcases are passed? Or is there any way that I can perform like IF test case passed, THEN grade ++, something like that?

    Thanks a lot!

  • Doctest is not able to compile on OSX

    Doctest is not able to compile on OSX

    Description

    I am trying to get my Travis CI build working with doctest (I'm switching from Catch to this for performance), but my build is not working on OSX (It is for Linux). In my Travis CI logs, I see the following error:

    Undefined symbols for architecture x86_64:
      "std::__1::basic_ostream<char, std::__1::char_traits<char> >& std::__1::operator<<<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
          doctest::String doctest::detail::stringifyBinaryExpr<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, char [6]>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, char const*, char const (&) [6]) in hello_world_test.cpp.o
    ld: symbol(s) not found for architecture x86_64
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[2]: *** [test/test_runner] Error 1
    make[1]: *** [test/CMakeFiles/test_runner.dir/all] Error 2
    make: *** [all] Error 2
    

    Steps to reproduce

    I'm using CMake, and my invocation command is:

    cmake -DCMAKE_BUILD_TYPE=$BUILD_TYPE -DCMAKE_CXX_COMPILER=$COMPILER -DBUILD_TESTS=ON ..
    

    (COMPILER is set to clang++ and BUILD_TYPE is set to Debug and Release, both of which fail)

    The CMake configuration I am using is (for flags):

    if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror")
        set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")
        set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -O2")
    elseif (CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
        # ...
    endif(CMAKE_CXX_COMPILER_ID MATCHES "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
    

    And the test configuration:

    set(TEST_SOURCES
        factorial_test.cpp
        hello_world_test.cpp
    )
    
    add_library(doctest INTERFACE)
    target_include_directories(doctest INTERFACE 
        "${CMAKE_SOURCE_DIR}/third_party/doctest" # Contains single header
    )
    
    add_executable(test_runner test_runner.cpp ${TEST_SOURCES})
    target_link_libraries(test_runner Project-Name-lib doctest)
    
    add_test(all_tests test_runner)
    

    Extra information

    • doctest version: v1.2.8
    • Operating System: Travis CI OSX XCode image 9.2
    • Compiler+version: AppleClang 9.0.0.9000039
  • Logo Proposal for Doctest

    Logo Proposal for Doctest

    Hi, In response to your request for Logo, I am very grateful to be able to collaborate in your project.

    I need a short review about Doctest to start with the sketches. I can improve the existing one or create something totally new and different. You can tell me your suggestions.

  • [Feature] Better integration with tools (VS Code Test Adapter Extension)

    [Feature] Better integration with tools (VS Code Test Adapter Extension)

    Description

    The "Catch2 and Google Test Explorer" Extension for Visual Studio Code has experimental support for doctest. However, several tests with the same name but in different tests suites can't be run. Also, the test results can't be displayed reliably inline in the source code. This could be fixed if some additional information was available from the command line.

    Could you add the possibility to list the test suites and test cases with file names and line numbers from the command line?

    This would make it possible for the extension to work reliably and give VS Code users much better usability while using doctest.

    See: https://github.com/matepek/vscode-catch2-test-adapter/issues/143#issuecomment-566092840 And: https://github.com/matepek/vscode-catch2-test-adapter/issues/143#issuecomment-566139062

  • Add default printers for enums

    Add default printers for enums

    I've added an assertion for a function returning an enum and the enum value. When the test failed I've got pretty informative failure output {?} == {?}...

    I don't intend to write a custom printer for my enum type, but still want to see readable values when a test fails. I've workaround the problem by casting to int, but I'd prefer if the library does this for me.

  • Slower than Catch in realistic test cases

    Slower than Catch in realistic test cases

    Hi,

    I did some benchmarking of doctest on my machine (Linux, gcc-4.9.3). I adapted a bit your Python script to work on Linux (with_gcc = 1 and removed the forced CMake generator).

    First, I can confirm that in the simple benchmark case, it is indeed faster to compile than Catch by a large margin. However, this is not a very realistic test case.

    I have modified the benchmark to generate 50 files, each with 25 test cases and each with 10 CHECK (using a variable and not two constants). Here are the results:

    Catch: 1 minute 56 seconds Doctest: 2 minutes 32 seconds

    In a realistic test case, doctest is significantly slower than Catch. I can see the same thing when I replace Catch by doctest in one of my large test case of my ETL library.

    Do you have any idea why this happen ?

    I can only guess that the overhead comes from the templates used to extract lhs and rhs or by the macros generating the test cases.

  • [PROJECT ANNOUNCEMENT] Looking for maintainers for Doctest

    [PROJECT ANNOUNCEMENT] Looking for maintainers for Doctest

    Working on doctest has taught me two very important lessons: how to prioritize and how to say no, and now it's time to apply them to my life. I can no longer maintain doctest properly and that's evident by my inactivity for the past 8 months - I haven't touched C++ professionally in almost 2 years and I've moved on to other things.

    I invite anyone interested in the development & maintenance of the framework to join the Discord server. I just moved doctest to a GitHub organization as suggested here and will add whoever is interested as a member. I'll release a version or two and will stick around for some time as people join in order to resolve any disputes and respond to questions and at some point, I'll promote the ones that have shown the most interest to admins & owners of the repository and the Discord server - I won't leave but I hope that by that time others would be able to reach consensus on contentious issues and I'll redirect any donations to the maintainers once this transition period is over.

    Doctest doesn't require too much work (unless new features are added) - mostly the occasional compiler bugfix & support in issues. The design goals of the framework should be followed - what made doctest successful is the art of saying no and keeping it light & easy to use.

    EDIT: some more info - https://github.com/doctest/doctest/issues/554#issuecomment-991190934

    Best regards, Viktor

  • Refactor stringification

    Refactor stringification

    So StringMaker and StringStream act as a pretty much completely parallel structure. This structure will be eradicated. For the first draft I have simply removed the StringMaker's body, attaching it's head to StringStream's body.

    The customization points are broken, as well as a few other features, namely raw memory stringification likely among others.

    This (hopefully) finally fixes #571 for good!

  • doctest 2.4.9: Pointer comparison in MSVC

    doctest 2.4.9: Pointer comparison in MSVC

    Description

    From doctest 2.4.8. to 2.4.9, there seems to be a change in the way pointers are compared. Trivial example below:

        DOCTEST_TEST_CASE("object equality test")
        {
            const auto a = new int();
            const auto b = a;
    
            //DOCTEST_CHECK(a == b); // compile error
            DOCTEST_CHECK((a == b)); // OK
        }
    
    error LNK2019: unresolved external symbol "public: static void __cdecl doctest::detail::filldata<void const *>::fill(class std::basic_ostream<char,struct std::char_traits<char> > *,void const *)" ([email protected][email protected]@[email protected]@@[email protected][email protected]@[email protected]@@[email protected]@[email protected]) referenced in function "public: struct doctest::detail::Result __cdecl doctest::detail::Expression_lhs<int * const &>::operator==<int * const &>(int * const &)" ([email protected][email protected]@[email protected]@@[email protected]@[email protected])
    

    Looks like doctest is treating the pointers as strings?

    Is this an expected new change?

    Steps to reproduce

    Run the attached minimal example (configure with CMake).

    Extra information

    • doctest version: v2.4.9
    • Operating System: W10
    • Compiler+version: VS 2022 17.2.4

    doctest-bug.zip

  • Regression: Compilation error with ICC in 2.4.9 (identifier

    Regression: Compilation error with ICC in 2.4.9 (identifier "__FUNCSIG__" is undefined)

    Description

    When updating the test suite of nlohmann/json, the test suite could no longer be compiled with ICPC.

    (see https://github.com/nlohmann/json/runs/6949564760?check_suite_focus=true for the failed CI run and https://github.com/nlohmann/json/pull/3545 for the related PR)

    Steps to reproduce

    • Check out develop branch of https://github.com/nlohmann/json
    • Replace tests/thirdparty/doctest/doctest.h with Doctest 2.4.9 (the develop branch currently uses 2.4.6)
    • Compile the tests suite with IPCC 2021.5.0.20211109

    Extra information

    • doctest version: v2.4.9
    • Operating System: Ubuntu 20.04.3 LTS
    • Compiler+version: IPCC 2021.5.0.20211109

    The error message is:

    /__w/json/json/tests/thirdparty/doctest/doctest.h(1067): error: identifier "__FUNCSIG__" is undefined
          String ret = __FUNCSIG__; // class doctest::String __cdecl doctest::toString<TYPE>(void)
                       ^
              detected during instantiation of "<unnamed>::value_in_range_of_testITERATOR<std::tuple<Type, Rest...>>::value_in_range_of_testITERATOR(const char *, unsigned int, int) [with Type=trait_test_arg<int32_t={__int32_t={signed int}}, int32_t={__int32_t={signed int}}, true, true>, Rest=<trait_test_arg<int32_t={__int32_t={signed int}}, uint32_t={__uint32_t={unsigned int}}, true, false>, trait_test_arg<uint32_t={__uint32_t={unsigned int}}, int32_t={__int32_t={signed int}}, false, true>,
                        trait_test_arg<uint32_t={__uint32_t={unsigned int}}, uint32_t={__uint32_t={unsigned int}}, true, true>, trait_test_arg<int32_t={__int32_t={signed int}}, int64_t={__int64_t={signed long}}, false, false>, trait_test_arg<int32_t={__int32_t={signed int}}, uint64_t={__uint64_t={unsigned long}}, true, false>, trait_test_arg<uint32_t={__uint32_t={unsigned int}}, int64_t={__int64_t={signed long}}, false, false>, trait_test_arg<uint32_t={__uint32_t={unsigned int}},
                        uint64_t={__uint64_t={unsigned long}}, true, false>, trait_test_arg<int64_t={__int64_t={signed long}}, int32_t={__int32_t={signed int}}, true, true>, trait_test_arg<int64_t={__int64_t={signed long}}, uint32_t={__uint32_t={unsigned int}}, true, true>, trait_test_arg<uint64_t={__uint64_t={unsigned long}}, int32_t={__int32_t={signed int}}, false, true>, trait_test_arg<uint64_t={__uint64_t={unsigned long}}, uint32_t={__uint32_t={unsigned int}}, true, true>,
                        trait_test_arg<int64_t={__int64_t={signed long}}, int64_t={__int64_t={signed long}}, true, true>, trait_test_arg<int64_t={__int64_t={signed long}}, uint64_t={__uint64_t={unsigned long}}, true, false>, trait_test_arg<uint64_t={__uint64_t={unsigned long}}, int64_t={__int64_t={signed long}}, false, true>, trait_test_arg<uint64_t={__uint64_t={unsigned long}}, uint64_t={__uint64_t={unsigned long}}, true, true>>]" at line 195 of "/__w/json/json/tests/src/unit-bjdata.cpp"
    

    This is the code in question

    template <typename T>
    String toString() {
    #if DOCTEST_MSVC >= 0 && DOCTEST_CLANG == 0 && DOCTEST_GCC == 0
        String ret = __FUNCSIG__; // class doctest::String __cdecl doctest::toString<TYPE>(void) // ERROR HERE
        String::size_type beginPos = ret.find('<');
        return ret.substr(beginPos + 1, ret.size() - beginPos - static_cast<String::size_type>(sizeof(">(void)")));
    #else
        String ret = __PRETTY_FUNCTION__; // doctest::String toString() [with T = TYPE]
        String::size_type begin = ret.find('=') + 2;
        return ret.substr(begin, ret.size() - begin - 1);
    #endif
    }
    

    Maybe IPCC is not properly detected and __PRETTY_FUNCTION__ should be used instead of __FUNCSIG__.

  • MESSAGE in lambda outputs CHECK_MESSAGE's message even if it's not failure.

    MESSAGE in lambda outputs CHECK_MESSAGE's message even if it's not failure.

    Description

    Steps to reproduce

    #define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
    #include "https://raw.githubusercontent.com/onqtam/doctest/dev/doctest/doctest.h"
    #include <functional>
    
    TEST_CASE("Strange behavior")
    {
        CHECK_MESSAGE([]() {
            MESSAGE("message!!");
            return true;
            }(), 
            "lambda Failed!!");
    }
    

    This outputs...

    [doctest] doctest version is "2.4.8"
    [doctest] run with "--help" for options
    ===============================================================================
    <source>:5:
    TEST CASE:  Strange behavior
    
    <source>:8: MESSAGE: message!!
      logged: lambda Failed!!
    
    ===============================================================================
    [doctest] test cases: 1 | 1 passed | 0 failed | 0 skipped
    [doctest] assertions: 1 | 1 passed | 0 failed |
    [doctest] Status: SUCCESS!
    

    https://godbolt.org/z/z1aqdjj1h

    I expected it outputs like that...

    [doctest] doctest version is "2.4.8"
    [doctest] run with "--help" for options
    ===============================================================================
    <source>:5:
    TEST CASE:  Strange behavior
    
    <source>:8: MESSAGE: message!!
    ===============================================================================
    [doctest] test cases: 1 | 1 passed | 0 failed | 0 skipped
    [doctest] assertions: 1 | 1 passed | 0 failed |
    [doctest] Status: SUCCESS!
    

    Extra information

    • doctest version: v2.4.8
    • Operating System: (godbolt)
    • Compiler+version: MSVC, Clang, GCC...latest

    Why this matters?

    I'm using libraries with monad interfaces in my code, like tl::optional or tl::expected. I sometimes make unit test like...

    tl::optional<MyData> funcToTest();
    
    TEST_CASE("MyData test")
    {
        CHECK_MESSAGE(funcToTest().map(
        [&](MyData data)
        {
            ProcessData(data);
            Message(data.toString());
        }).has_value(),
        "funcToTest() failed");
    }
    

    thanks.

  • Failure with intel-19.0.x compiler

    Failure with intel-19.0.x compiler

    Description

    Simple test of two strings fails with intel-19 compiler

    Steps to reproduce

    bash-4.2$ cat test.C
    #define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
    #include "doctest.h"
    #include <string>
    namespace
    {
        TEST_CASE("string test")
        {
          std::string val = "Greg";
          CHECK(std::string("Greg") == val);
        }
    };
    

    Extra information

    • doctest version 2.4.8
    • Operating System: Linux redhat rhel7
    • Compiler+version:
    bash-4.2$ icpc --version
    icpc (ICC) 19.0.4.243 20190416
    Copyright (C) 1985-2019 Intel Corporation.  All rights reserved.
    

    Compilation output

    test.C(9): error: no operator "==" matches these operands
                operand types are: doctest::detail::Expression_lhs<const std::__cxx11::string> == std::__cxx11::string
            CHECK(std::string("Greg") == val);
            ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_vector.h(1596): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_multiset.h(896): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const multiset<_Key, _Compare, _Alloc>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_set.h(913): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const set<_Key, _Compare, _Alloc>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_multimap.h(1045): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const multimap<_Key, _Tp, _Compare, _Alloc>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_map.h(1380): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const map<_Key, _Tp, _Compare, _Alloc>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_tree.h(1533): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_tree.h(406): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const _Rb_tree_iterator<_Val>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/unique_ptr.h(694): note: this candidate was rejected because arguments do not match
          operator==(nullptr_t, const unique_ptr<_Tp, _Dp>& __x) noexcept
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/unique_ptr.h(689): note: this candidate was rejected because arguments do not match
          operator==(const unique_ptr<_Tp, _Dp>& __x, nullptr_t) noexcept
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/unique_ptr.h(683): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const unique_ptr<_Tp, _Dp>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/tuple(1397): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const tuple<_TElements...>& __t,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/array(252): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const array<_Tp, _Nm>& __one, const array<_Tp, _Nm>& __two)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/streambuf_iterator.h(204): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const istreambuf_iterator<_CharT, _Traits>& __a,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/system_error(311): note: this candidate was rejected because arguments do not match
        operator==(const error_condition& __lhs,
        ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/system_error(304): note: this candidate was rejected because arguments do not match
        operator==(const error_condition& __lhs, const error_code& __rhs) noexcept
        ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/system_error(297): note: this candidate was rejected because arguments do not match
        operator==(const error_code& __lhs, const error_condition& __rhs) noexcept
        ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/system_error(292): note: this candidate was rejected because arguments do not match
        operator==(const error_code& __lhs, const error_code& __rhs) noexcept
        ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/basic_string.h(5841): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/basic_string.h(5829): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const _CharT* __lhs,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/basic_string.h(5815): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const basic_string<_CharT>& __lhs,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/basic_string.h(5807): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/allocator.h(152): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const allocator<_Tp>&, const allocator<_Tp>&)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/allocator.h(146): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const allocator<_T1>&, const allocator<_T2>&)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/postypes.h(216): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const fpos<_StateT>& __lhs, const fpos<_StateT>& __rhs)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(1124): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const move_iterator<_Iterator>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(1118): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const move_iterator<_IteratorL>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(337): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const reverse_iterator<_IteratorL>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(299): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const reverse_iterator<_Iterator>& __x,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_pair.h(443): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/ext/new_allocator.h(155): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const new_allocator<_Tp>&, const new_allocator<_Tp>&)
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(866): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
          ^
    /sierra/sntools/SDK/compilers/gcc/7.2.0-RHEL6/include/c++/7.2.0/bits/stl_iterator.h(859): note: this candidate was rejected because at least one template argument could not be deduced
          operator==(const __normal_iterator<_IteratorL, _Container>& __lhs,
          ^
    
    compilation aborted for test.C (code 2)
    
  • [Feature] CMakeLists.txt enhancement: system headers and a static library target with implementation

    [Feature] CMakeLists.txt enhancement: system headers and a static library target with implementation

    Hi,

    I'd like to propose two enhancements to the CMakeLists.txt:

    1. Add "SYSTEM" to target_include_directories for the doctest interface target. Or use an option to control it, like the fmt libbrary does.
    2. Add a target called doctest_with_impl, similar to doctest_with_main, but without the main() function. I found this is more useful for complex projects with different modules having their own testing executables.

    Thanks!

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
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
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
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

Jun 15, 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
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

Jun 23, 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

Jan 24, 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

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

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

Apr 16, 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
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
Simple, fast, accurate single-header microbenchmarking functionality for C++11/14/17/20

ankerl::nanobench ankerl::nanobench is a platform independent microbenchmarking library for C++11/14/17/20. #includ

Jun 18, 2022
Practical mutation testing tool for C and C++

Mull Mull is a tool for Mutation Testing based on LLVM/Clang with a strong focus on C and C++ languages. For installation and usage please refer to th

Jun 16, 2022
proftest is a C application for testing the quality of different operating system APIs for profiling.

proftest is a C application for testing the quality of different operating system APIs for profiling.

Jul 23, 2021
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