STATIC_REQUIRE/STATIC_CHECK and code coverage

[frankosterfeld]

When using STATIC_REQUIRE/STATIC_CHECK to test constexpr functions, gcov ignores these checks as they are not executed at runtime, reporting a lower code coverage than I actually have.

CATCH_CONFIG_RUNTIME_STATIC_REQUIRE solves that, but then I lose the advantages of STATIC_REQUIRE.

It would be great if there was a define that would make STATIC_REQUIRE assert both at compile time and runtime, or custom macros doing that (not sure what good names would be...), like

#define STATIC_REQUIRE2(expr) { STATIC_REQUIRE(expr); REQUIRE(expr); } // naive version; also note I didn't solve the naming problem

[jan-moeller]

I think this is part of a (much) bigger problem: I find myself writing (and hence testing) more and more constexpr code. And for any at least partially constexpr-enabled type I write, I have to duplicate every test - once to test at runtime, and once to test in a constexpr context. So, what this usecase really needs is test cases and sections that run both at runtime and at compile time. Something along the lines of:

// This test case is executed in a constexpr context and also at runtime
TEST_CASE("Something", "[compiletime][runtime]") {
    my_type t;
    REQUIRE(t.foo() == 42);
}

Unfortunately, when I superficially looked at catch2's internals, I had no idea how to implement such a thing. I assume it's more or less impossible with the syntax I'm showing here. As a workaround, I tend to wrap my test setup in a lambda and then call that twice.

TEST_CASE("Something", "") {
    constexpr auto test = []() {
        my_type t;
        return t.foo();
    };
    REQUIRE(test() == 42);
    STATIC_REQUIRE(test() == 42);
    // Or use your STATIC_REQUIRE2
}

This is still very suboptimal, in particular since it doesn't really work with catch's idea of sections and sharing of setup code.