catchorg / catchorg/Catch2

[Feature] Convenience TEST_CASE macro for standardized test structure

Open
#1,154 11 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
21.5k
Forks
3.5k
Avg merge
3d 16h
Merged PRs (30d)
2

Description

The way we currently setup our unit tests is that we have 1 translation unit per class that we test. So if I have a class contained in files `MyClass.hpp` and `MyClass.cpp`, then the corresponding Catch unit test cases are contained in a file called `TestMyClass.cpp`. We have a basic skeleton that we follow in each of these unit test translation units:

```cpp
#include
#include "MyClass.hpp"

#define MAIN_TAG "[MyClass]"

TEST_CASE("Verify Construction", MAIN_TAG)
{
// do unit testing here
}
```

Furthermore, we may have other tests with description "Verify Construction", so to make the names unique we do:

```cpp
TEST_CASE(MAIN_TAG " Verify Construction", MAIN_TAG)
```

This defines a pattern that we follow, but also introduces boilerplate. To simplify this even further, I created an intermediate include file for catch named `UnitTestFramework.hpp` with the following:

```cpp
#pragma once
#include

#define ZIOSK_TEST_CASE(description, ...) \
TEST_CASE(MAIN_TAG " " description, MAIN_TAG __VA_ARGS__)
```

So now to define the test cases for MyClass, I do:

```cpp
#include "UnitTestFramework.hpp"
#define MAIN_TAG "[MyClass]"

ZIOSK_TEST_CASE("Verify Construction")
{
}
```

This obviously cleans things up really nicely. Also the way it's setup allows for you to append more tags to the `MAIN_TAG` if you so wish. The reason `MAIN_TAG` exists is so that we standardize a way to execute test cases assigned to the class (`MAIN_TAG` always identifies the class being tested by that one test CPP file).

Would such a convenience macro make sense as common functionality provided by Catch? I think the flexibility that Catch provides allows a lot of different test structures, but it would be nice if there were vanity macros provided by Catch to help enforce a structure like this that I feel would work nicely for most projects.

Happy to discuss and submit a PR if this is headed in a good direction. Would appreciate feedback from the developers.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.