To make this all work, I had to remove the stringification cache from matchers. In theory, this can cause performance penalty in cases where single matcher instance is stringified multiple times, but in practice this does not happen much, and the difference is surprisingly small anyway, because the performance of stringification is already horrible and full of allocating strings just to throw them away. The matcher combinators need P2738 from C++26 to be `constexpr`. Closes #3091
156 lines
4.4 KiB
Markdown
156 lines
4.4 KiB
Markdown
<a id="top"></a>
|
|
# Other macros
|
|
|
|
This page serves as a reference for macros that are not documented
|
|
elsewhere. For now, these macros are separated into 2 rough categories,
|
|
"assertion related macros" and "test case related macros".
|
|
|
|
## Assertion related macros
|
|
|
|
* `CHECKED_IF` and `CHECKED_ELSE`
|
|
|
|
`CHECKED_IF( expr )` is an `if` replacement, that also applies Catch2's
|
|
stringification machinery to the _expr_ and records the result. As with
|
|
`if`, the block after a `CHECKED_IF` is entered only if the expression
|
|
evaluates to `true`. `CHECKED_ELSE( expr )` work similarly, but the block
|
|
is entered only if the _expr_ evaluated to `false`.
|
|
|
|
> `CHECKED_X` macros were changed to not count as failure in Catch2 3.0.1.
|
|
|
|
Example:
|
|
```cpp
|
|
int a = ...;
|
|
int b = ...;
|
|
CHECKED_IF( a == b ) {
|
|
// This block is entered when a == b
|
|
} CHECKED_ELSE ( a == b ) {
|
|
// This block is entered when a != b
|
|
}
|
|
```
|
|
|
|
* `CHECK_NOFAIL`
|
|
|
|
`CHECK_NOFAIL( expr )` is a variant of `CHECK` that does not fail the test
|
|
case if _expr_ evaluates to `false`. This can be useful for checking some
|
|
assumption, that might be violated without the test necessarily failing.
|
|
|
|
Example output:
|
|
```
|
|
main.cpp:6:
|
|
FAILED - but was ok:
|
|
CHECK_NOFAIL( 1 == 2 )
|
|
|
|
main.cpp:7:
|
|
PASSED:
|
|
CHECK( 2 == 2 )
|
|
```
|
|
|
|
* `SUCCEED`
|
|
|
|
`SUCCEED( msg )` is mostly equivalent with `INFO( msg ); REQUIRE( true );`.
|
|
In other words, `SUCCEED` is for cases where just reaching a certain line
|
|
means that the test has been a success.
|
|
|
|
Example usage:
|
|
```cpp
|
|
TEST_CASE( "SUCCEED showcase" ) {
|
|
int I = 1;
|
|
SUCCEED( "I is " << I );
|
|
}
|
|
```
|
|
|
|
* `STATIC_REQUIRE` and `STATIC_CHECK`
|
|
|
|
> `STATIC_REQUIRE` was [introduced](https://github.com/catchorg/Catch2/issues/1362) in Catch2 2.4.2.
|
|
|
|
`STATIC_REQUIRE( expr )` is a macro that can be used the same way as a
|
|
`static_assert`, but also registers the success with Catch2, so it is
|
|
reported as a success at runtime. The whole check can also be deferred
|
|
to the runtime, by defining `CATCH_CONFIG_RUNTIME_STATIC_REQUIRE` before
|
|
including the Catch2 header.
|
|
|
|
Example:
|
|
```cpp
|
|
TEST_CASE("STATIC_REQUIRE showcase", "[traits]") {
|
|
STATIC_REQUIRE( std::is_void<void>::value );
|
|
STATIC_REQUIRE_FALSE( std::is_void<int>::value );
|
|
}
|
|
```
|
|
|
|
> `STATIC_CHECK` was [introduced](https://github.com/catchorg/Catch2/pull/2318) in Catch2 3.0.1.
|
|
|
|
`STATIC_CHECK( expr )` is equivalent to `STATIC_REQUIRE( expr )`, with the
|
|
difference that when `CATCH_CONFIG_RUNTIME_STATIC_REQUIRE` is defined, it
|
|
becomes equivalent to `CHECK` instead of `REQUIRE`.
|
|
|
|
Example:
|
|
```cpp
|
|
TEST_CASE("STATIC_CHECK showcase", "[traits]") {
|
|
STATIC_CHECK( std::is_void<void>::value );
|
|
STATIC_CHECK_FALSE( std::is_void<int>::value );
|
|
}
|
|
```
|
|
|
|
* `STATIC_REQUIRE_THAT` and `STATIC_CHECK_THAT`
|
|
|
|
> `STATIC_REQUIRE_THAT` and `STATIC_CHECK_THAT` was introduced in Catch2 X.Y.Z
|
|
|
|
`STATIC_{REQUIRE,CHECK}_THAT` are analogous to `STATIC_{REQUIRE,CHECK}`,
|
|
but for matchers. They are always defined, even if the current compiler
|
|
does not support `constexpr` matchers, but in that case the compilation
|
|
will always fail.
|
|
|
|
Just like `STATIC_{REQUIRE,CHECK}`, `STATIC_{REQUIRE,CHECK}_THAT` can be
|
|
delayed into runtime through the `CATCH_CONFIG_RUNTIME_STATIC_REQUIRE`
|
|
configuration option.
|
|
|
|
Example:
|
|
```cpp
|
|
TEST_CASE("Constexpr support for matchers", "[constexpr][matchers]") {
|
|
STATIC_REQUIRE_THAT( 1, MatchAll() );
|
|
STATIC_REQUIRE_THAT( 1, MatchAll() && MatchAll() );
|
|
STATIC_REQUIRE_THAT( 1, MatchAll() || MatchAll() );
|
|
STATIC_REQUIRE_THAT( 1, !!MatchAll() );
|
|
}
|
|
```
|
|
|
|
|
|
## Test case related macros
|
|
|
|
* `REGISTER_TEST_CASE`
|
|
|
|
`REGISTER_TEST_CASE( function, description )` let's you register
|
|
a `function` as a test case. The function has to have `void()` signature,
|
|
the description can contain both name and tags.
|
|
|
|
Example:
|
|
```cpp
|
|
REGISTER_TEST_CASE( someFunction, "ManuallyRegistered", "[tags]" );
|
|
```
|
|
|
|
_Note that the registration still has to happen before Catch2's session
|
|
is initiated. This means that it either needs to be done in a global
|
|
constructor, or before Catch2's session is created in user's own main._
|
|
|
|
|
|
* `DYNAMIC_SECTION`
|
|
|
|
> Introduced in Catch2 2.3.0.
|
|
|
|
`DYNAMIC_SECTION` is a `SECTION` where the user can use `operator<<` to
|
|
create the final name for that section. This can be useful with e.g.
|
|
generators, or when creating a `SECTION` dynamically, within a loop.
|
|
|
|
Example:
|
|
```cpp
|
|
TEST_CASE( "looped SECTION tests" ) {
|
|
int a = 1;
|
|
|
|
for( int b = 0; b < 10; ++b ) {
|
|
DYNAMIC_SECTION( "b is currently: " << b ) {
|
|
CHECK( b > a );
|
|
}
|
|
}
|
|
}
|
|
```
|