This adds UNSCOPED_INFO macro, creating a log message that is stored
until the end of next assertion or the end of test case, whichever comes
first. These messages are not scoped locally, unlike messages created by
INFO macro.
This generator collects values from the underlying generator until it
has a specified amount of them, and then returns them in one "chunk".
In case the underlying generator does not have enough elements for
a specific chunk, the left-over elements are discarded.
Closes#1538
The REQUIRE_THROWS and CATCH_REQUIRE_THROWS macros have
a subtle inconsistency in their implementation which can
cause a warning if [-Wunused-value] is used.
This commit changes CATCH_REQUIRE_THROWS so it has the
same implementation as REQUIRE_THROWS
It looks like REQUIRE_THROWS was change in commit
fae0fa4ec but not CATCH_REQUIRE_THROWS.
Similar changes for CATCH_CHECK_THROWS
support for generating test cases based on multiple template template
types combined with template arguments for each of the template template
types specified
e.g.
```
TEMPLATE_PRODUCT_TEST_CASE("template product","[template]",
(std::tuple, std::pair, std::map),
((int,float),(char,double),(int,char)))
```
will effectively create 9 test cases with types:
std::tuple<int,float>
std::tuple<char,double>
std::tuple<int,char>
std::pair<int,float>
std::pair<char, double>
std::pair<int,char>
std::map<int,float>
std::map<char,double>
std::map<int,char>
Tested type is accessible in test case body as TestType
Unique name is created by appending ` - <index>` to test name
since preprocessor has some limitations in recursions
Closes#1454
This adds support for templated tests and test methods via
`TEMPLATE_TEST_CASE` and `TEMPLATE_TEST_CASE_METHOD` macros. These
work mostly just like their regular counterparts*, but take an
unlimited** number of types as their last arguments.
* Unlike the plain `TEST_CASE*` macros, the `TEMPLATE*` variants
require a tag string.
** In practice there is limit of about 300 types.
By default, it expands into a `static_assert` + `SUCCEED` pair, but
it can also be deferred to runtime by defining
`CATCH_CONFIG_RUNTIME_STATIC_REQUIRE`, which causes it to expand
into plain old `REQUIRE`.
Closes#1362Closes#1356
issue #1360
It is possible to have multple given contexts in a single BDD scenario;
if you have to type 'and' in the GIVEN description; it's very likely you
need an AND.
A generic AND is not possible, thus a AND_GIVEN is added to complement
the AND_WHEN and AND_THEN.
Can be used without needing to increase indent:
SCENARIO("...") {
GIVEN("...")
AND_GIVEN("...") {
WHEN("...") {
THEN("...") {
// ...
}
}
}
}
would correctly output, when requested/needed:
Given: ...
And given: ...
When: ...
Then: ...
The padding had to be increased by a character in the output message, to
continue to be uniform.
The support is to be considered experimental, that is, the interfaces,
the first party generators and helper functions can change or be removed
at any point in time.
Related to #850
* Assertions are defined into (void)(0) no-op
* SECTIONs are defined away (leaving {} as scope)
* TEST_CASEs and TEST_CASE_METHODs are not registered.
* REGISTER_TEST_CASE is defined into (void)(0) no-op
* METHOD_AS_TEST_CASE is defined away
- this file excluded from the CATCH_CONFIG_DISABLE_MATCHERS path.
- matchers are always compiled in to the impl file
- _THROWS_WITH macros are still available with matchers disabled - but only the ones that take a string
- tests that use matchers have #ifdefs, so the whole SelfTest project can compile with matchers disable.
The toggle is `CATCH_CONFIG_DISABLE_MATCHERS` and the only use is
to speed up compilation of small TUs. For large ones it is likely
insignificant, because the speed up is constant relative to
number of tests/assertions in TU.
