GTest Catch2 Behavior Tests

---
name: gtest-catch2-behavior-tests
description: Generate GTest or Catch2 unit tests for C++ core logic behavior
---

You generate focused unit tests for C++ core logic using Google Test (GTest) or Catch2, depending on which framework the project already uses. If neither is present, default to GTest.

## Detection

1. Check for an existing test framework:
   - GTest: look for `find_package(GTest)` or `gtest/gtest.h` includes.
   - Catch2: look for `catch2/catch_test_macros.hpp` or `catch.hpp` includes.
2. If both are present, match the framework used by the nearest existing test file.
3. Identify the build system (CMake, Meson, Bazel) so generated tests integrate without manual wiring.

## Test Generation Rules

### Scope

- Test observable behavior, not implementation details. Target public and internal API surfaces of classes and free functions.
- Each test exercises one logical behavior. Name tests as `BehaviorUnderCondition_ExpectedOutcome`.
- Do not test private methods directly. If a private method matters, test it through the public interface that calls it.

### Structure (GTest)

```cpp
#include <gtest/gtest.h>
#include "module_under_test.h"

TEST(ModuleName, BehaviorUnderCondition_ExpectedOutcome) {
    // Arrange
    auto sut = createSystemUnderTest();
    // Act
    auto result = sut.doSomething(input);
    // Assert
    EXPECT_EQ(result, expected);
}
```

### Structure (Catch2)

```cpp
#include <catch2/catch_test_macros.hpp>
#include "module_under_test.h"

TEST_CASE("ModuleName: behavior under condition yields expected outcome", "[module]") {
    // Arrange
    auto sut = createSystemUnderTest();
    // Act
    auto result = sut.doSomething(input);
    // Assert
    REQUIRE(result == expected);
}
```

### Coverage Targets

For each function or class under test, generate tests for:

1. **Normal path** — typical valid inputs produce correct output.
2. **Edge cases** — empty containers, zero values, maximum values, null/nullptr where applicable.
3. **Error conditions** — invalid input triggers the documented error behavior (exception, error code, std::expected, std::optional returning nullopt).
4. **RAII / resource behavior** — if the type manages resources, verify correct construction, move semantics, and destruction side effects.

### Assertions

- GTest: prefer `EXPECT_*` for non-fatal checks, `ASSERT_*` only when subsequent lines depend on the result.
- Catch2: prefer `REQUIRE` for critical checks, `CHECK` for non-fatal.
- For floating-point: use `EXPECT_NEAR` (GTest) or `Approx` (Catch2).
- For exceptions: use `EXPECT_THROW(expr, ExceptionType)` (GTest) or `REQUIRE_THROWS_AS(expr, ExceptionType)` (Catch2).

### What to Avoid

- Do not mock types unless the dependency performs I/O or is explicitly non-deterministic. Prefer real objects for pure logic.
- Do not use `sleep`, timers, or wall-clock assertions. If testing async behavior, use synchronization primitives or mock the clock.
- Do not duplicate the implementation logic inside the test (e.g., re-computing the expected value with the same algorithm). Use known literal values.
- Do not generate tests for trivial getters/setters unless they have validation logic.

## Output Format

1. One test file per source file under test, named `<source>_test.cpp`.
2. Include a comment at the top: `// Tests for <source>.cpp — generated by gtest-catch2-behavior-tests`.
3. Group related tests using test fixtures (GTest `TEST_F`) or Catch2 `SECTION` blocks when setup is shared.
4. If the project uses CMake, append the test target registration (`add_test` / `gtest_discover_tests`) as a comment block at the end of the file.

## Verification

After generating tests:
- Confirm the file compiles: `cmake --build build --target <test_target>` or equivalent.
- Confirm tests pass: `ctest --test-dir build --output-on-failure` or `./build/<test_binary>`.
- Report any tests that fail and explain whether the failure indicates a bug in the source or an incorrect test assumption.