[support] identical names for test suites? #40

FSund opened this Issue Oct 3, 2016 · 3 comments


None yet

2 participants

FSund commented Oct 3, 2016 edited

I recently ran into a problem while compiling, and it turned out it was caused by having multiple TEST_SUITEs with the same name. I kept getting compilation errors like this:

mysubclass.o: In function `DOCTEST_ANON_FOR_SEMICOLON_3()':
mysubclass.cpp:(.text+0x0): multiple definition of `DOCTEST_ANON_FOR_SEMICOLON_3()'
myclass.o:myclass.cpp:(.text+0x370): first defined here

I now know that TEST_SUITEs need to be uniquely defined by design, but I had to investigate the documentation to realize this.

So the biggest issue is that the compilation errors aren't really helpful for figuring out the cause of the errors. Would it be possible to add some functionality that warns against multiply defined TEST_SUITEs?

FSund commented Oct 3, 2016 edited

Hmm... After further investigation, it seems like my errors were caused by something else.

I'm running into some trouble implementing doctest in my large project, and of course I am unable to reproduce the problems in a minimal example.

EDIT: I was using TEST_SUITE instead of TEST_CASE, and it seems like this caused some problems. It seems like tests inside suites are not running by default..?

onqtam commented Oct 3, 2016 edited

Weird. The strings passed to both TEST_CASE() and TEST_SUITE() need not be unique.

Test cases can have the same name - it's up to the user. Also if a test is written in a header (which the framework supports) - it is bound to end up in multiple source files - but it will be registered only once - not because of it's name but because of where it was written (based on __FILE__ and __LINE__).

Test cases in multiple source files may be in the same test suite by using TEST_SUITE("the same string") before the test cases - with the same string for the test suite - like this:

// a.cpp

TEST_CASE("") { /* some math stuff */ }
// b.cpp

TEST_CASE("") { /* some math stuff */ }

As far as the linker error - so weird - that's the last thing I expected to fail. To force the ; semicolon after the TEST_SUITE() macro I add a dummy forward declaration of a function at the end - like this: void DOCTEST_ANONYMOUS(DOCTEST_ANON_FOR_SEMICOLON_)()

If you have tried to add a function body after the test suite macro - I would imagine that would lead to errors - like this:

TEST_SUITE("the ts") { // <<<< THIS IS BAD - not intended for such use - might lead to errors
    // asserts...

This might lead to linker errors if the same thing is done in multiple source files - or if done only in one place - might lead to asserts that are never called - since this is not a real test case.

The thing is that when you "declare" a test suite with TEST_SUITE("some string"); you actually push some string as the test suite name for the test cases that follow in the current source file - until TEST_SUITE_END is encountered (which internally calls TEST_SUITE("") with an empty string).

Does this explain the problem you are having? What part of the documentation would you recommend to be improved?

Perhaps I should stop generating this dummy forward declaration and instead make a dummy typedef - so when a function body is appended instead of a semicolon - a proper compile time error is printed.

FSund commented Oct 5, 2016 edited

Seems like I didn't read the documentation properly, sorry for the confusion.

I definitely expected TEST_SUITE to behave the same way as TEST_CASE, when a body is appended. Seems like this, plus the fact that I got TEST_SUITE and TEST_CASE mixed up were cause for most of my errors.

I would suggest perhaps adding TEST_SUITE_BEGIN() to match TEST_SUITE_END(), and make TEST_SUITE() {} behave nicely with a body appended.

EDIT: I'm closing this issue, and making a new one with the suggestions above.

@FSund FSund closed this Oct 5, 2016
@onqtam onqtam changed the title from Test suites can't have identical names to [support] identical names for test suites? Oct 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment