f24569a1b4
This rework changes two important things 1) the output redirect is deactivated while control is given to the reporters. This means that combining reporters that write to stdout with capturing reporters, e.g. `./tests -s -r console -r junit::out=junit.xml`, no longer leads to the capturing reporter seeing all the output from the other reporter captured. Trying this with the `SelfTest` binary would previously lead to JUnit spending **hours** trying to escape all of ConsoleReporter's output and write it to the output file. I actually ended up killing the process after 3 hours, during which the JUnit reporter wrote something like 50 MBs of output to a file. 2) The redirect object's lifetime is tied to the `RunContext`, instead of being constructed for every partial test case run separately. This has no effect on the basic StreamRedirect, but improves the FileRedirect significantly. Previously, running many tests in single process with this redirect (e.g. running `SelfTest -r junit`) would cause later tests to always fail before starting, due to exceeding the limit of temporary files. For the current `SelfTest` binary, the old implementation would lead to **295** test failures from not being able to initiate the redirect. The new implementation completely eliminates them. ---- There is one downside to the new implementation of FileRedirect, specific to Linux. Running the `SelfTest` binary on Linux causes 3-4 tests to have no captured stdout/stderr, even though the tests were supposed to be writing there (there was no output to the actual stdout/stderr either, the output was just completely lost). Since this never happen for smaller test case sets, nor does it reproduce on other platforms, this implementation is still strictly better than the old one, and thus it can get reasonably merged. |
||
---|---|---|
.conan | ||
.github | ||
CMake | ||
data/artwork | ||
docs | ||
examples | ||
extras | ||
fuzzing | ||
src | ||
tests | ||
third_party | ||
tools | ||
.bazelrc | ||
.clang-format | ||
.clang-tidy | ||
.gitattributes | ||
.gitignore | ||
appveyor.yml | ||
BUILD.bazel | ||
CMakeLists.txt | ||
CMakePresets.json | ||
CODE_OF_CONDUCT.md | ||
codecov.yml | ||
conanfile.py | ||
Doxyfile | ||
LICENSE.txt | ||
mdsnippets.json | ||
meson_options.txt | ||
meson.build | ||
MODULE.bazel | ||
README.md | ||
SECURITY.md | ||
WORKSPACE.bazel |
What is Catch2?
Catch2 is mainly a unit testing framework for C++, but it also provides basic micro-benchmarking features, and simple BDD macros.
Catch2's main advantage is that using it is both simple and natural. Test names do not have to be valid identifiers, assertions look like normal C++ boolean expressions, and sections provide a nice and local way to share set-up and tear-down code in tests.
Example unit test
#include <catch2/catch_test_macros.hpp>
#include <cstdint>
uint32_t factorial( uint32_t number ) {
return number <= 1 ? number : factorial(number-1) * number;
}
TEST_CASE( "Factorials are computed", "[factorial]" ) {
REQUIRE( factorial( 1) == 1 );
REQUIRE( factorial( 2) == 2 );
REQUIRE( factorial( 3) == 6 );
REQUIRE( factorial(10) == 3'628'800 );
}
Example microbenchmark
#include <catch2/catch_test_macros.hpp>
#include <catch2/benchmark/catch_benchmark.hpp>
#include <cstdint>
uint64_t fibonacci(uint64_t number) {
return number < 2 ? number : fibonacci(number - 1) + fibonacci(number - 2);
}
TEST_CASE("Benchmark Fibonacci", "[!benchmark]") {
REQUIRE(fibonacci(5) == 5);
REQUIRE(fibonacci(20) == 6'765);
BENCHMARK("fibonacci 20") {
return fibonacci(20);
};
REQUIRE(fibonacci(25) == 75'025);
BENCHMARK("fibonacci 25") {
return fibonacci(25);
};
}
Note that benchmarks are not run by default, so you need to run it explicitly
with the [!benchmark]
tag.
Catch2 v3 has been released!
You are on the devel
branch, where the v3 version is being developed.
v3 brings a bunch of significant changes, the big one being that Catch2
is no longer a single-header library. Catch2 now behaves as a normal
library, with multiple headers and separately compiled implementation.
The documentation is slowly being updated to take these changes into account, but this work is currently still ongoing.
For migrating from the v2 releases to v3, you should look at our documentation. It provides a simple guidelines on getting started, and collects most common migration problems.
For the previous major version of Catch2 look into the v2.x
branch
here on GitHub.
How to use it
This documentation comprises these three parts:
- Why do we need yet another C++ Test Framework?
- Tutorial - getting started
- Reference section - all the details
More
- Issues and bugs can be raised on the Issue tracker on GitHub
- For discussion or questions please use our Discord
- See who else is using Catch2 in Open Source Software or commercially.