A way to refrain from polluting “#define” space for users of tested code?

[atimholt]

I’m writing a templated geometry library based on rational numbers, and I’m having a great time using doctest in it.

However, I’d like to allow users of my library to also use doctest without them inadvertently re-testing my code or having to worry about include order. At first, I thought I might just use a preprocessor guard to allow me to ignore the defined-ness state of DOCTEST_CONFIG_DISABLE in the body of my code (turn it on/off at the start of each of my files, put it back how it was at the end), but then, of course, I realized this couldn't possibly work, since once doctest.h is included, it would necessarily define all the macros I’m trying not to pollute the “#define” space with.

I then tried custom-named macros, with DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES defined, followed by another #include "doctest.h", but even when I put a #define DOCTEST_CONFIG_DISABLE before include, the effects off a previous include’s macro definition were felt and my tests still registered.

Is there already support for what I’m trying to do? Could the functionality of DOCTEST_CONFIG_NO_SHORT_MACRO_NAMES be extended to not affecting the state of already defined short macros, but still allowing another include to define the long macros in a different DOCTEST_CONFIG_DISABLEed (on or off) state, ready for namespace-esque custom redefinition?

[onqtam]

I'm not sure I fully understand your case.

So far your library seems header-only (with no tests in the header) and the only source files are with tests - so users of the library will not have them in their production code when using only the header.

A potential workflow problem I see is if you write tests in your header, and ship the header with the following:

#define DOC_TEST_CONFIG_DISABLE
#include "doctest.h"

// your tests that are supposed to be disabled in the 'production' header - when released to customers.

I think an option for your situation (if I sort-of understand it) is to add a 'tag' to all your tests (add a specific string in the test case names):

TEST_CASE("[myLibrary] Testing Point.hpp") {
    // ...

and then the user can exclude them with filters when he is providing the main() entry point like this:

doctest::Context context(argc, argv);
context.addFilter("test-case-exclude", "*myLibrary*");

This way you won't have to think about disabling them for the user.

If you can clarify a bit more the situation I might be able to come up with a different solution.

[atimholt]

So far your library seems header-only (with no tests in the header)…

Yeah, I’ve since moved the tests out of the main source. You can see how I had it in earlier changesets.

To be honest, I think the real answer is not to “pollute” libraries (libraries specifically) with test code, so I went with that. The solution you gave actually does almost exactly what I want if the filter is added in my own code inside a pre-processor guard (I mean, I haven’t tried it, since I’ve moved on, but still).

Thanks for the help.