-
-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A way to refrain from polluting “#define” space for users of tested code? #32
Comments
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:
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):
and then the user can exclude them with filters when he is providing the main() entry point like this:
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. |
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. |
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 oncedoctest.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 differentDOCTEST_CONFIG_DISABLE
ed (on or off) state, ready for namespace-esque custom redefinition?The text was updated successfully, but these errors were encountered: