lightweight single header C++ library for embedding tests within your codebase - like documentation
in doctest's example everything links against the .dll which has the test runner (where
DOCTEST_CONFIG_IMPLEMENT is defined). There are 3 .dlls in total in the doctest example: 1 which has the test runner, 1 which just contains tests and 1 which is loaded at runtime by the program itself - also without a test runner.
@syaifulnizamyahya I guess your executable links to the 2 .dlls but in order to have a single test runner across many .dlls and .exes you'll need everything to link against the .dll which contains the test runner.
so your second .dll will need to link against the first .dll
but then you'll have 2 separate test registries, so you should do what I proposed earlier
I have added my testing here https://github.com/syaifulnizamyahya/doctest
@onqtam Please have a look if you have time. Thanks.
see the doctest dll example again -
DOCTEST_CONFIG_IMPLEMENT is defined in a single place
in your case there are 2 such cases
test runner == the implementation of the framework
when you include doctest.h you get the interface
when you define
DOCTEST_CONFIG_IMPLEMENT and then include doctest.h you get the interface + the implementation
think of the doctest header as 2 files attached together - a header file (the interface) and a .cpp file (the implementation - the test runner)
when you #define
DOCTEST_CONFIG_IMPLEMENT you pull the contents of that fictional .cpp along
I'm sorry but I'm not going to be able to look at your example in the near future - I'm knee-deep in work - I haven't had a free weekend in the past couple of months
hopefully my comments are helpful - if you're still not able to get it to work - it would be great if someone else helps. Otherwise I'll eventually get to helping with this, but I'm confident that the doctest dll example in the original repository should be enough to get the full picture
about from_dll - see the comment here:
the "dll" target in that CMake project only has a single test case. The executable links to it, but since it doesn't need anything from there (and doesn't know there is a self-registering test), and the dll doesn't dllexport anything - no .lib file will be created for it - or something like that - I've already forgotten
but in your case you have dlls with tests, and production code which you test. I guess you are already exporting some of that production code and using it from the main executable - you should already have a .lib file for your dlls
so you can just ignore the from_dll stuff from doctest's examples
I have successfully created a simple project with multiple dlls using doctest. You can find it here if you have time. https://github.com/syaifulnizamyahya/doctest_multiple_dlls
The simple project have 2 dlls, dllA and dllB. I have a testrunner, which calls DOCTEST_CONFIG_IMPLEMENT. I have a testexecutable which calls doctest:Contest(). Each dlls calls DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL.
My question is, is this the best way to do it? Are there any other alternatives?
@syaifulnizamyahya This is the best way if you want to have a single test runner (a single place where DOCTEST_CONFIG_IMPLEMENT is defined) - that way all the tests from all .dlls will be registered in a single place. This way you could choose which dlls to load from the executable and thus choose which tests to have registered. You could also use the command line filtering functionality to choose tests from specific .cpp files or based on a pattern or test suite - you could use test suites for the different dlls.
A potential alternative might be to have a test runner in each dll but then you would need to have DOCTEST_CONFIG_IMPLEMENT in each dll and also create and use a doctest::Context object in the dllMain of each dll.
In the cmake target link libraries
target_link_libraries(${LIBRARY_NAME}
doctest
)
in cpp
#define DOCTEST_CONFIG_IMPLEMENTATION_IN_DLL
#define DOCTEST_CONFIG_IMPLEMENT
#define DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES
#include "doctest.h"
DOCTEST_TEST_CASE("testrunner") {
DOCTEST_INFO("From testrunner\n");
}
@syaifulnizamyahya thanks for catching that bug - that INFO cannot be used from within a dll! I logged it here: onqtam/doctest#306
When my tests fails, i get a breakpoint on where the test fails. Is it possible to disable this? i might have multiple fail tests during development and only interested in the failed tests when im ready(done development). I notice there are some defines that might be related to this. but im not sure which one.
DOCTEST_CONFIG_NO_TRY_CATCH_IN_ASSERTS or DOCTEST_CONFIG_NO_EXCEPTIONS or DOCTEST_CONFIG_NO_EXCEPTIONS_BUT_WITH_ALL_ASSERTS or DOCTEST_CONFIG_SUPER_FAST_ASSERTS? What is the workflow that you guys use?
@syaifulnizamyahya what you need is
You could also set it by default in your
--no-breaks from the command line options: https://github.com/onqtam/doctest/blob/master/doc/markdown/commandline.mdYou could also set it by default in your
main() function with the ability to override it through the command line: https://github.com/onqtam/doctest/blob/master/doc/markdown/main.md (the option is used in the example as well - but as an override - move that above the call to applyCommandLine() and it will be a default instead of an override)
@onqtam Hi Viktor. Would it be possible to separate logging macro and test macro? I want to use test shorthand macro but doctest logging macro conflicted with my logging setup. Specifically, INFO shorthand macro from doctest conflicted with my loggin INFO macro. while i can disable it myself in the doctest header, i wonder if you can make it officially separated?
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 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