Тестирование на C++ (навык агента)

Рабочий процесс тестирования, ориентированный на агенты, для современного C++ (C++17/20) с использованием GoogleTest/GoogleMock и CMake/CTest.

Когда использовать

• При написании новых тестов на C++ или исправлении существующих тестов
• Разработка плана покрытия модульными и интеграционными тестами для компонентов на C++
• Добавление тестового покрытия, проверки прохождения CI или защиты от регрессионных сбоев
• Настройка рабочих процессов CMake/CTest для согласованного выполнения
• Расследование сбоев тестов или нестабильного поведения
• Включение санитайзеров для диагностики проблем с памятью и гонок условий

Когда НЕ следует использовать

• Реализация новых функций продукта без изменений в тестах
• Крупномасштабные рефакторинги, не связанные с покрытием тестов или сбоями
• Настройка производительности без регрессионных тестов для проверки
• Проекты, не связанные с C++, или задачи, не относящиеся к тестированию

Основные концепции

• Цикл TDD: красный → зелёный → рефакторинг (сначала тесты, минимальное исправление, затем очистка).
• Изоляция: отдавайте предпочтение инъекции зависимостей и фиксам, а не глобальному состоянию.
• Структура тестов: tests/unit, tests/integration, tests/testdata.
• Моки против фейков: моки — для взаимодействий, фейки — для поведения с состоянием.
• Обнаружение тестов с помощью CTest: используйте gtest_discover_tests() для стабильного обнаружения тестов.
• Сигнал CI: сначала запускайте поднабор тестов, затем полный набор с помощью --output-on-failure.

Рабочий процесс TDD

Следуйте циклу «RED → GREEN → REFACTOR»:

1. КРАСНЫЙ: напишите тест, который проваливается и фиксирует новое поведение
2. ЗЕЛЕНЫЙ: внесите минимальное изменение, чтобы тест прошел
3. РЕФАКТОРИНГ: приведите код в порядок, пока тесты остаются «зелёными»

// tests/add_test.cpp
#include 

int Add(int a, int b); // Provided by production code.

TEST(AddTest, AddsTwoNumbers) { // RED
  EXPECT_EQ(Add(2, 3), 5);
}

// src/add.cpp
int Add(int a, int b) { // GREEN
  return a + b;
}

// REFACTOR: simplify/rename once tests pass

Примеры кода

Базовый модульный тест (gtest)

// tests/calculator_test.cpp
#include 

int Add(int a, int b); // Provided by production code.

TEST(CalculatorTest, AddsTwoNumbers) {
    EXPECT_EQ(Add(2, 3), 5);
}

Фикстура (gtest)

// tests/user_store_test.cpp
// Pseudocode stub: replace UserStore/User with project types.
#include 
#include 
#include 
#include 

struct User { std::string name; };
class UserStore {
public:
    explicit UserStore(std::string /*path*/) {}
    void Seed(std::initializer_list /*users*/) {}
    std::optional Find(const std::string &/*name*/) { return User{"alice"}; }
};

class UserStoreTest : public ::testing::Test {
protected:
    void SetUp() override {
        store = std::make_unique(":memory:");
        store->Seed({{"alice"}, {"bob"}});
    }

    std::unique_ptr store;
};

TEST_F(UserStoreTest, FindsExistingUser) {
    auto user = store->Find("alice");
    ASSERT_TRUE(user.has_value());
    EXPECT_EQ(user->name, "alice");
}

Мок (gmock)

// tests/notifier_test.cpp
#include 
#include 
#include 

class Notifier {
public:
    virtual ~Notifier() = default;
    virtual void Send(const std::string &message) = 0;
};

class MockNotifier : public Notifier {
public:
    MOCK_METHOD(void, Send, (const std::string &message), (override));
};

class Service {
public:
    explicit Service(Notifier ¬ifier) : notifier_(notifier) {}
    void Publish(const std::string &message) { notifier_.Send(message); }

private:
    Notifier ¬ifier_;
};

TEST(ServiceTest, SendsNotifications) {
    MockNotifier notifier;
    Service service(notifier);

    EXPECT_CALL(notifier, Send("hello")).Times(1);
    service.Publish("hello");
}

Краткое руководство по CMake/CTest

# CMakeLists.txt (excerpt)
cmake_minimum_required(VERSION 3.20)
project(example LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

include(FetchContent)
# Prefer project-locked versions. If using a tag, use a pinned version per project policy.
set(GTEST_VERSION v1.17.0) # Adjust to project policy.
FetchContent_Declare(
  googletest
  # Google Test framework (official repository)
  URL https://github.com/google/googletest/archive/refs/tags/${GTEST_VERSION}.zip
)
FetchContent_MakeAvailable(googletest)

add_executable(example_tests
  tests/calculator_test.cpp
  src/calculator.cpp
)
target_link_libraries(example_tests GTest::gtest GTest::gmock GTest::gtest_main)

enable_testing()
include(GoogleTest)
gtest_discover_tests(example_tests)

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build -j
ctest --test-dir build --output-on-failure

Запуск тестов

ctest --test-dir build --output-on-failure
ctest --test-dir build -R ClampTest
ctest --test-dir build -R "UserStoreTest.*" --output-on-failure

./build/example_tests --gtest_filter=ClampTest.*
./build/example_tests --gtest_filter=UserStoreTest.FindsExistingUser

Отладка сбоев

1. Повторно запустите отдельный тест, завершившийся с ошибкой, с помощью фильтра gtest.
2. Добавьте локальный логинг вокруг неудачного утверждения.
3. Запустите тест повторно с включенными санитайзерами.
4. После устранения первопричины расширьте набор тестов до полного набора.

Покрытие

Предпочтительно используйте настройки на уровне целевой платформы вместо глобальных флагов.

option(ENABLE_COVERAGE "Enable coverage flags" OFF)

if(ENABLE_COVERAGE)
  if(CMAKE_CXX_COMPILER_ID MATCHES "GNU")
    target_compile_options(example_tests PRIVATE --coverage)
    target_link_options(example_tests PRIVATE --coverage)
  elseif(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
    target_compile_options(example_tests PRIVATE -fprofile-instr-generate -fcoverage-mapping)
    target_link_options(example_tests PRIVATE -fprofile-instr-generate)
  endif()
endif()

GCC + gcov + lcov:

cmake -S . -B build-cov -DENABLE_COVERAGE=ON
cmake --build build-cov -j
ctest --test-dir build-cov
lcov --capture --directory build-cov --output-file coverage.info
lcov --remove coverage.info '/usr/*' --output-file coverage.info
genhtml coverage.info --output-directory coverage

Clang + llvm-cov:

cmake -S . -B build-llvm -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER=clang++
cmake --build build-llvm -j
LLVM_PROFILE_FILE="build-llvm/default.profraw" ctest --test-dir build-llvm
llvm-profdata merge -sparse build-llvm/default.profraw -o build-llvm/default.profdata
llvm-cov report build-llvm/example_tests -instr-profile=build-llvm/default.profdata

Санитайзеры

option(ENABLE_ASAN "Enable AddressSanitizer" OFF)
option(ENABLE_UBSAN "Enable UndefinedBehaviorSanitizer" OFF)
option(ENABLE_TSAN "Enable ThreadSanitizer" OFF)

if(ENABLE_ASAN)
  add_compile_options(-fsanitize=address -fno-omit-frame-pointer)
  add_link_options(-fsanitize=address)
endif()
if(ENABLE_UBSAN)
  add_compile_options(-fsanitize=undefined -fno-omit-frame-pointer)
  add_link_options(-fsanitize=undefined)
endif()
if(ENABLE_TSAN)
  add_compile_options(-fsanitize=thread)
  add_link_options(-fsanitize=thread)
endif()

Нестабильные тесты Защитные механизмы

• Никогда не используйте sleep для синхронизации; используйте условные переменные или латчи.
• Создавайте уникальные временные каталоги для каждого теста и всегда очищайте их.
• Избегайте зависимостей от реального времени, сети или файловой системы в модульных тестах.
• Используйте детерминированные начальные значения для рандомизированных входных данных.

Рекомендации

ЧТО СЛЕДУЕТ ДЕЛАТЬ

• Обеспечьте детерминированность и изолированность тестов
• Отдавайте предпочтение инъекции зависимостей, а не глобальным переменным
• Используйте ASSERT_* для предварительных условий, EXPECT_* для нескольких проверок
• Разделяйте модульные и интеграционные тесты с помощью меток CTest или каталогов
• Запускайте санитайзеры в CI для обнаружения проблем с памятью и гонки доступа

НЕ СЛЕДУЕТ

• Не полагайтесь на реальный время или сеть в модульных тестах
• Не используйте паузы (sleep) для синхронизации, если можно использовать переменную условия
• Не создавайте избыточных моков простых объектов-значений
• Не используйте ненадежное сопоставление строк для некритических логов

Распространенные ошибки

• Использование фиксированных путей к временным файлам → Создавайте уникальные временные каталоги для каждого теста и очищайте их.
• Ориентация на реальное время → Внедряйте собственный таймер или используйте поддельные источники времени.
• Нестабильные тесты параллелизма → Используйте переменные условий/защелки и ограниченные ожидания.
• Скрытое глобальное состояние → Сбрасывайте глобальное состояние в фикстурах или удаляйте глобальные переменные.
• Чрезмерное использование моков → Предпочитайте фики для поведения с состоянием и имитируйте только взаимодействия.
• Отсутствие запусков санитайзеров → Добавьте сборки с ASan/UBSan/TSan в CI.
• Покрытие в сборках, предназначенных только для отладки → Убедитесь, что в целях покрытия используются одинаковые флаги.

Дополнительное приложение: Фузинг / Тестирование свойств

Используйте только в том случае, если проект уже поддерживает LLVM/libFuzzer или библиотеку для тестирования свойств.

• libFuzzer: лучше всего подходит для чистых функций с минимальным вводом-выводом.
• RapidCheck: тесты на основе свойств для проверки инвариантов.

Минимальный набор тестов libFuzzer (псевдокод: заменить ParseConfig):

#include 
#include 
#include 

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    std::string input(reinterpret_cast(data), size);
    // ParseConfig(input); // project function
    return 0;
}

Альтернативы GoogleTest

• Catch2: только заголовки, выразительные матчеры
• doctest: лёгкий, с минимальными затратами на компиляцию