Unit test for ensuring conditionally compiled code in c++

Question

This is a standard C++ ASSERT macro defined in my code -

#ifndef DEBUG
#define ASSERT(n)
#else
#define ASSERT(n) \
if (!(n)){  \
    printf("%s - Failed ", #n); \
    printf("On %s ", __DATE__); \
    printf("At %s ", __TIME__); \
    printf("In File %s ", __FILE__); \
    printf("At Line %d\n", __LINE__); \
    exit(1);}
#endif

I want to ensure that my build always contains this code, by binding a unit test around it. The test should check that if #DEBUG preprocessor is not supplied (i.e. it is release mode), a conditional check applied in unit test should fail with ASSERT macro failing and containing the message given above.

Is there an established way to achieve this? I am using google test framework to achieve this, but unable to achieve the result. Test fails with standard assertion message, not the custom assertion I am trying it to fail with. My code is as below -

TEST(VerifyNormalInitialization, VerifyAssert)
{
    static int index = 0;
    static int num = 4;
    ASSERT(index == num);
    EXPECT_FATAL_FAILURE(ASSERT(index == num),"Failed");
}

what are the "standard" and "custom" assertion messages? Please include output and expected output in the question — 463035818_is_not_an_ai, Oct 26 '20 at 10:38
your own `ASSERT` calls `exit(1)`, thats going to be not easy to test for. Why reinvent the wheel in the first place? There is already `assert` — 463035818_is_not_an_ai, Oct 26 '20 at 10:39
`EXPECT_FATAL_FAILURE` only detects GoogleTest assertion failures. `exit(1)` would be caught only in a [death test](https://github.com/google/googletest/blob/release-1.8.0/googletest/docs/AdvancedGuide.md#death-tests), using `EXPECT_EXIT` or `EXPECT_DEATH`. — Yksisarvinen, Oct 26 '20 at 10:40
@idclev463035818 : Point taken about 'exit(1)'. Sounds like I am trying to split the hair. — Amogh Sarpotdar, Oct 26 '20 at 11:04
@Yksisarvinen : Thanks for pointing out death test, exploring it now. — Amogh Sarpotdar, Oct 26 '20 at 11:05

score 1 · Accepted Answer · answered Oct 26 '20 at 11:00

1

First the obvious the following raises only an error when DEBUG is defined.

ASSERT(index == num);
ASSERT(index != num);

For unit tests for both cases: production and development, you need to compile both ways.

You might effect that by your own #define/#undef DEBUG.

Good practice? I do not know; I was not aware that this was something worthwile testing. Maybe just a verification that ASSERTs are active during development. And that is something for an installation check.

answered Oct 26 '20 at 11:00

Joop Eggen

107,315
7
83
138

Thanks Joop! Idea behind unit test was to ensure other devs become aware that they have omitted the #defined assert macro in a compilation unit that is taking a few minutes to compile and build, and when run they wont find the failure information pointing to file and line number. A failing unit test would quickly highlight this. However, reading comments above and your answer, I get a feeling I am approaching this in wrong way and need to explore other options. – Amogh Sarpotdar Oct 26 '20 at 11:11
@AmoghSarpotdar I love this kind of safeguards for all eventualities, but there are some "efficiency" practices like skipping unit tests. Good luck. – Joop Eggen Oct 26 '20 at 11:29

score 0 · Answer 2 · answered Oct 26 '20 at 12:02

Consider

EXPECT_FATAL_FAILURE(if (!(index == num)){ ... },"Failed");

Does that look like valid C++? It is not.

Consider writing a macro which passes along #n, __FILE__ etc to a proper function. If you insist on using a macro alone, then it needs to be a single expression and not a statement, something along the lines of:

#define STR2(x) #x
#define STR(x) STR2(x)

#define ASSERT(n)                                          \
(                                                          \
  fprintf(stderr,                                          \
          #n " - Failed on " __DATE__ " at " __TIME__      \
          " in file " __FILE__ " at line " STR(__LINE__)   \
         ),                                                \
  exit(EXIT_FAILURE)                                       \
)

This is using compile-time string concatenation to prepare the whole string. Everything in this expression is string literals, and two string literals such as "hello" and "world" get concatenated by the pre-processor as "helloworld".

The "stringification" macros are just there to convert the integer __LINE__ into a string literal. Stringification - how does it work?

Note that the ), is the comma operator, which is used to allow two function calls in the same expression.

Unit test for ensuring conditionally compiled code in c++

2 Answers2