Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Viktor Kirilov
@onqtam
Do you mean that your source code also has a #define INFO ... which conflicts with the one from doctest? In that case you could use DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES and perhaps a proxy header for including doctest like this: https://github.com/onqtam/doctest/blob/master/examples/all_features/doctest_proxy.h
syaifulnizamyahya
@syaifulnizamyahya
@onqtam Hi Viktor. If I add comma to test case name, the tests are being ignored. Eg. DOCTEST_TEST_CASE("WorkspaceService - 1st") is fine, but if its DOCTEST_TEST_CASE("WorkspaceService , 1st")its being ignored. Not sure why.
Viktor Kirilov
@onqtam
@syaifulnizamyahya I just tried it and it doesn't matter if there is a comma in the name or not. But I tried it without any filters on the command line - are you using such? Perhaps this is a related issue: onqtam/doctest#297
syaifulnizamyahya
@syaifulnizamyahya
Yup. I believe its the same issue. Thanks.
syaifulnizamyahya
@syaifulnizamyahya
@onqtam Just curious. What mocking library have you use? What mocking library you are currently using? Why?
syaifulnizamyahya
@syaifulnizamyahya
I already looked at that links. I was expecting a more personal preference/experience actually. Anyway, thanks.
Viktor Kirilov
@onqtam
Well actually I've never used mocking, and even in my current company we use google test because it was already integrated when I joined and there is not big need to switch... And for google test if we need mocks we would use google mock.
Tim
@Gohlisch

Hey, I just started C++ programming and found DocTest. I was just wondering if my way of disabling tests is the correct one.

I followed the main.md and had no problems. When I tried #define DOCTEST_CONFIG_DISABLE the compiler couldn't find symbols like doctest::Context context etc (which wasn't surprising).

Is the correct way to put everything test related in a if(!DOCTEST_CONFIG_DISABLE) {...DocTest stuff here...} statement, so that the compiler ignores it?

Viktor Kirilov
@onqtam
@Gohlisch that's strange - can you paste the exact error messages you are getting? Compiler or linker errors? It should be as simple as defining DOCTEST_CONFIG_DISABLE for the entire project and it should continue to compile - including a custom main function which uses doctest::Context...
that's where the implementation of the Context class is defined when DOCTEST_CONFIG_DISABLE is defined - the methods are empty stubs precisely so that users don't need to do anything extra
Tim
@Gohlisch

math.cpp:

#define DOCTEST_CONFIG_DISABLE
#include "doctest.h" 
#include <iostream>

int add(int a, int b) {
    return a+b;
}

TEST_CASE("testing add func") {
    CHECK(add(0, 0) == 0);
    CHECK(add(1, 0) == 1);
    CHECK(add(1, 1) == 2);
    CHECK(add(0, -1) == -1);
    CHECK(add(-1, -1) == -2);
}

int main(int argc, char** argv) {
    doctest::Context context;
    context.setOption("abort-after", 5); 
    context.applyCommandLine(argc, argv);
    context.setOption("no-breaks", true);
    int res =  context.run();
    if(context.shouldExit())    
        return res;             
    std::cout << add(1, 2);
    return res;
}

using: g++ math.cpp -o math -std=c++2a
leads to
Undefined symbols for architecture x86_64: "doctest::Context::shouldExit()", referenced from: _main in math-161803.o "doctest::Context::applyCommandLine(int, char const* const*)", referenced from: _main in math-161803.o "doctest::Context::run()", referenced from: _main in math-161803.o "doctest::Context::setOption(char const*, int)", referenced from: _main in math-161803.o "doctest::Context::Context(int, char const* const*)", referenced from: _main in math-161803.o "doctest::Context::~Context()", referenced from: _main in math-161803.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I use #define DOCTEST_CONFIG_IMPLEMENT everything seems to work as intended.

Viktor Kirilov
@onqtam
@Gohlisch oh - you shouldn't swap out one for the other - #define DOCTEST_CONFIG_IMPLEMENT must always be present in at least one .cpp file, and whether you have defined DOCTEST_CONFIG_DISABLE globally is a completely separate matter. Those stubs I pointed to require DOCTEST_CONFIG_IMPLEMENT.
so to disable all tests you should define DOCTEST_CONFIG_DISABLE in addition to DOCTEST_CONFIG_IMPLEMENT
Tim
@Gohlisch
Ah, all right. I can't believe I haven't tried that. Thanks for your quick help.
Artem
@artem-bochkarev
Hello. I have troubles with using doctest together with unity builds. Solution from sample "executable_dll_and_plugin" fails unity build in case if "implementation_2.cpp" was included by unity before "implementation.cpp". Could it be configured by splitting doctest into separate headers? Or is it better just to exclude "implementation.cpp" from unity builds?
Viktor Kirilov
@onqtam
@artem-bochkarev I'd advise you to indeed just exclude that file from unity builds (or make it so that implementation.cpp ends up first in the unity file, however I assume that should already be the case because of the CMake file: add_library(implementation SHARED implementation.cpp implementation_2.cpp) - implementation.cpp is listed first... i don't know why that's not the case in your setup... perhaps you've reordered the .cpp files?)
Artem
@artem-bochkarev
@onqtam I not use this sample. I make the same in our project, so filenames is different. And yes, it works after excluding implementation file from unity build.
Thanks for the response.
Honey-API
@Honey-API

Hello everyone, I got some issues to compile with i686-w64-mingw32-g++ a shared library (.dll) project.
Here is what I get when I compile :

x86_64-w64-mingw32-g++ -shared -std=gnu++0x -fPIC -Wl,--allow-shlib-undefined,-soname,libgs1user.2.dll sources.cpp -static-libgcc -static-libstdc++ -o libgs1user.2.0.0.dll
...
/usr/bin/x86_64-w64-mingw32-ld: /tmp/cchQKq4R.o:gs1user.cpp:(.text+0x126b): undefined reference to __imp__ZN7doctest6detail9TestSuitemlEPKc' /usr/bin/x86_64-w64-mingw32-ld: /tmp/cchQKq4R.o:gs1user.cpp:(.text+0x1277): undefined reference toimpZN7doctest6detail12setTestSuiteERKNS0_9TestSuiteE'
/usr/bin/x86_64-w64-mingw32-ld: /tmp/ccfCh4GW.o:c_dsfid.cpp:(.text+0x24): undefined reference to `doctest::String::String(char const*)'
...

Everything is fine with g++ for Linux compilation
Can anyone help me ?

Honey-API
@Honey-API
Maybe the good question is : Is doctest compatible with mingw32 for cross-compiling to Windows
But what is strange is that even with "#define DOCTEST_CONFIG_DISABLE" I got the "undefined" error when compiling
Honey-API
@Honey-API

Okay, I found the fix... :

  • just forgot to add "doctest/parts/doctest.cpp" to the compiler
  • placed "#define DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL" before "#include "../libraries/doctest/doctest.h""
    Just put the problem writed here help me to find what's was wrong.

By the way cross-compiling to Windows using mingw32 works using the lib header "mingw-std-threads/mingw.mutex.h" and replaced <mutex> by :

'#if defined(_WIN64) || defined(_WIN32)
' #include "../mingw-std-threads/mingw.mutex.h"
'#else
' #include <mutex>
'#endif

in doctest.hpp and doctest.cpp

Viktor Kirilov
@onqtam
@Honey-API Good to hear that you got it to work!
naufraghi
@naufraghi:matrix.org
[m]

Hi all, thanks Viktor for doctest! I just started using it (I like the cargo test experience), but I found that perhaps the https://github.com/onqtam/doctest/blob/master/doc/markdown/build-systems.md#cmake example is not in sync. If the single file inside your own repository intro is correct, the minimal snipped should be without find_packages and without doctest in target_link_libraries, something like:

add_executable(test test.cpp <other-sources>)
target_compile_features(test PRIVATE cxx_std_17)
target_link_libraries(test <other-libs>)

May I propose a PR to update the docs?

Viktor Kirilov
@onqtam
@naufraghi:matrix.org hmmm perhaps the single file inside your own repository part should be dropped instead - I assume everyone can handle a header file in their repo and the example there should instead showcase how to use doctest as a package
not to mention that the target_compile_features(test PRIVATE cxx_std_17) line is also unnecessary... C++11 is required and I assume that's the default by now for most compilers
naufraghi
@naufraghi:matrix.org
[m]

I've tried a simple clone, and it fails the same, because of some Finddoctest.cmake missing. In case of a simple clone a minimal snippet:

include_directories(doctest/doctest)
add_subdirectory(doctest)

Should go, with target_link_libraries(test doctest). I just leave it here for the posterity ;)

zeroxia
@zeroxia

Hi. I have a project like below, I can control A, and I'm trying to use doctest in it.

project
|
+-- A
+-- B
+-- SO
+-- EXE

SO expects A and B to provide static libraries, and SO will combine them to create a final shared lib, say libOUTPUT.so.
Then EXE will link to libOUTPUT.so.

I can by default define DOCTEST_CONFIG_DISABLE, then everything builds OK.
But I do want to remove this macro, and builds the entire project as well, though doctest is not used by SO or EXE at all.
In this case (doctest enabled), A itself has executable targets and builds without problem. But EXE linking to SO has problem:

XXX.so: undefined reference to `doctest::detail::ResultBuilder::react() const'
XXX.so: undefined reference to `doctest::detail::TestCase::operator*(char const*)'
XXX.so: undefined reference to `doctest::detail::setTestSuite(doctest::detail::TestSuite const&)'
XXX.so: undefined reference to `doctest::String::~String()'
XXX.so: undefined reference to `doctest::detail::regTest(doctest::detail::TestCase const&)'
XXX.so: undefined reference to `doctest::detail::TestSuite::operator*(char const*)'
XXX.so: undefined reference to `doctest::detail::ResultBuilder::translateException()'
XXX.so: undefined reference to `doctest::detail::ResultBuilder::ResultBuilder(doctest::assertType::Enum, char const*, int, char const*, char const*, char const*)'
XXX.so: undefined reference to `doctest_detail_test_suite_ns::getCurrentTestSuite()'
XXX.so: undefined reference to `doctest::detail::ResultBuilder::log()'
XXX.so: undefined reference to `doctest::detail::TestCase::TestCase(void (*)(), char const*, unsigned int, doctest::detail::TestSuite const&, char const*, int)'
collect2: error: ld returned 1 exit status
In A, I do inlcude a dummy source, to be included in the static library:
#define DOCTEST_CONFIG_IMPLEMENT
#include "doctest.h"
zeroxia
@zeroxia
Actually this setup builds OK on Windows with Visual Studio 2015, but the error happens on linux, a Centos 7 system, GCC version 6.5.0. I try to add definition of DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL, but error is the same.
On MacOS it also builds without problem.
zeroxia
@zeroxia

The symbol ResultBuilder::ResultBuilder does exist in static lib from A:

$ nm -gC libA.a | grep -i ResultBuilder::ResultBuilder
0000000000003d6a T doctest::detail::ResultBuilder::ResultBuilder(doctest::assertType::Enum, char const*, int, char const*, char const*, char const*)
0000000000003d6a T doctest::detail::ResultBuilder::ResultBuilder(doctest::assertType::Enum, char const*, int, char const*, char const*, char const*)

But in the SO, the symbol is undefined:

$ nm -gC libOUTPUT.so | grep doctest
                 U doctest_detail_test_suite_ns::getCurrentTestSuite()
                 U doctest::detail::setTestSuite(doctest::detail::TestSuite const&)
                 U doctest::detail::ResultBuilder::translateException()
                 U doctest::detail::ResultBuilder::log()
                 U doctest::detail::ResultBuilder::ResultBuilder(doctest::assertType::Enum, char const*, int, char const*, char const*, char const*)
                 U doctest::detail::regTest(doctest::detail::TestCase const&)
                 U doctest::detail::TestCase::TestCase(void (*)(), char const*, unsigned int, doctest::detail::TestSuite const&, char const*, int)
                 U doctest::detail::TestCase::operator*(char const*)
                 U doctest::detail::TestSuite::operator*(char const*)
                 U doctest::String::~String()
                 U doctest::detail::ResultBuilder::react() const
zeroxia
@zeroxia
It seems that adding -Wl,--whole-archive when creating the shared library can resolve this issue.
Viktor Kirilov
@onqtam
Hi @zeroxia ,
have you inspected the dll examples in the doctest repository? There are 2-3 different scenarios there which work on all platforms.
zeroxia
@zeroxia
I checked executable_dll_and_plugin, it seems that it just uses the macro DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL. I tried this but not working.
exe_with_static_libs, this example introduced some tricky CMake utility, initially I tried to use this to register test cases in depedent libraries, but not working either. But now I'm using object libraries inside my component now.
I'm considering to make the SO component to enable "whole-archive" linking, then my current source tree can build with doctest enabled in my component.
But I'm not sure if this is the root cause. Or there is indeed something I can do inside my component "A" to solve this linking issue.
Viktor Kirilov
@onqtam
could you produce a minimal example that reproduces the problem and upload it in a github repo?
that would be easiest for me to inspect what's going on on Linux
zeroxia
@zeroxia
OK, I will try to prepare a demo project, but I doubt it could reproduce with a simplistic dummy project. If I can reproduce it, I'll open an issue on github. Thank you.
zeroxia
@zeroxia
@onqtam The problem I posted earlier about Linux with undefined symbols. The cause is that on those Linux building dockers, cmake is 3.11, so I disabled object library, used regular STATIC libraries. If I use object library on those Linux platforms, the total build can go without problem, like Windows and OS X.
zeroxia
@zeroxia
Hello, I see the following feature is in consideration: queries for the current test case - name (and probably decorators)
Is there some way to find out some ID of the current test case automatically?
zeroxia
@zeroxia
In side a TEST_CASE(), I want to launch another process, executing the same executable, and the same TEST_CASE(), with different set up (e.g., an extra custom command line option, or some environment variable). So I need to pass some command line option to the newly started process, like ./myexe -tc TEST_CASE_NAME --my-options
Looks like this is the answer: onqtam/doctest#345
Viktor Kirilov
@onqtam
@zeroxia yes, that's what I would have pointed you at
Joakim Thorén
@Kuxe

@onqtam Hi Viktor, I was trying to use the "integration with the output window of Visual Studio 2019 for failing tests" with a CMake project. I RMB-click the root CMakeLists.txt and then press "Run Tests" from the drop-down menu. The tests run and output is shown in console. Failing tests are shown with a file and its linenumber in "Show output from: CMake":

Excerpt from output:

[...]
[doctest] doctest version is "2.4.6"
[doctest] run with "--help" for options
===============================================================================
..\..\..\tests\collatz_test.cpp(9):
TEST SUITE: collatz
TEST CASE:  Test unique by name to doctest
..\..\..\tests\collatz_test.cpp(11): ERROR: CHECK( 42 == 41 ) is NOT correct!
  values: CHECK( 42 == 41 )
===============================================================================
[...]

However, double-clicking on collatz_test.cpp(11): just prints "The system cannot find the file specified." in Visual Studio's status bar.

Could this be an issue with the "integration with the output window of Visual Studio 2019 for failing tests"-feature used with relative path ..\..\..\tests\collatz_test.cpp instead of an absolute path? Is it possible to somehow build my doctest-binary so that it outputs absolute paths?

2 replies
Viktor Kirilov
@onqtam
@Kuxe glad you sorted this issue out :)
doctest just uses whatever __FILE__ ends up being, which is determined by the compiler & the build environment.
zeroxia
@zeroxia

On Mac OS, I've defined -DDOCTEST_CONFIG_DISABLE and -DDOCTEST_CONFIG_USE_STD_HEADERS.

For a very simple TEST_CASE:

TEST_CASE("UT.util.chrono.getSystemTimeMillis")
{
    auto millis = getSystemTimeMillis();
    auto sys_time = static_cast<int64_t>(tn::simple_time::system_time() * 1000);

    CHECK_LT(std::abs(millis - sys_time), 2);
}

There are warnings:

warning: unused variable 'millis' [-Wunused-variable]
    auto millis = getSystemTimeMillis();
         ^
warning: unused variable 'sys_time' [-Wunused-variable]
    auto sys_time = static_cast<int64_t>(tn::simple_time::system_time() * 1000);

I have two questions:

  1. Although DOCTEST_CONFIG_DISABLE is defined, the code is still compiled into the object file?
  2. Any good practice to fix such warnings when the disable macro is defined?
Viktor Kirilov
@onqtam
@zeroxia when DOCTEST_CONFIG_DISABLE is defined all test cases are turned into uninstantiated templates - that means that the code must continue to parse, but it won't end up in the final object file (as it is never instantiated as a template). All asserts are also turned into a no-op so that it gets parsed faster. However that does indeed result in such warnings for unused variables and I'd suggest suppressing those warnings when doctest is disabled (you can use DOCTEST_CLANG_SUPPRESS_WARNING("-Wunused-variable"))
zeroxia
@zeroxia:matrix.org
[m]
Thank you for the thorough explanation.