Тестирование кода: пишем первые юнит-тесты на C++ с Google Test

Представь, что ты собрал шкаф из IKEA. Все детали на месте, инструкция понятна, шурупы закручены. Но выдержит ли он вес книг? Ты дёргаешь каждую полку. Шатается — подтягиваешь крепление. Держится крепко — отлично, можно загружать. Юнит-тест — это такое же «дёрганье» для твоего кода. Ты проверяешь каждую функцию по отдельности и убеждаешься: она делает именно то, что задумано.

Ты уже умеешь писать код на C++, компилировать его и запускать через терминал. Эти навыки мы освоили в статьях «Первые шаги в C++: ставим среду, пишем и запускаем код» и «Основы командной строки: Bash и PowerShell для разработчиков». Теперь давай научимся доказывать, что твой код работает правильно. Не «вроде бы работает», а точно.

К концу статьи ты напишешь свой первый юнит-тест, проверишь с его помощью алгоритм линейного поиска и соберёшь собственную шпаргалку с командами.

1. Что такое юнит-тесты и зачем они тебе

Представь конвейер на заводе. Деталь не сразу попадает в готовую машину — сначала она проходит отдел технического контроля. Специальный автомат проверяет её размеры, прочность, соответствие чертежу. Только после этого деталь отправляется дальше.

Юнит-тест — это такой автомат для твоей функции. Он проверяет один маленький кусочек программы (функцию или метод) в полной изоляции от остального кода. Подал на вход определённые данные — сравнил результат с ожиданием. Совпало — тест зелёный. Не совпало — красный.

Зачем тратить время на тесты? Есть три причины. Первая: ты ловишь ошибки до того, как их увидит пользователь. Вторая: ты перестаёшь проверять код вручную. Это экономит часы. Третья: тесты становятся живой документацией. Новый человек открывает тесты и сразу понимает, что функция должна делать, а что — нет.

В основе любого теста лежит принцип AAA. Три этапа, которые легко запомнить через нашу метафору со шкафом. Arrange — ты раскладываешь детали из коробки, сверяешься с инструкцией. В коде: готовишь входные данные. Act — закручиваешь шурупы, собираешь каркас. В коде: вызываешь тестируемую функцию. Assert — дёргаешь полку и смотришь, держится ли она. В коде: сравниваешь результат с ожиданием.

Ещё два термина, которые пригодятся. Тестовый случай — это проверка одного конкретного сценария. Например: «что вернёт функция сложения, если передать 2 и 3?». Тестовый набор — это группа тестов, которые проверяют одну и ту же функцию с разных сторон.

Принцип AAA в тестировании

2. GoogleTest: главные макросы для проверок

GoogleTest — это фреймворк для тестирования на C++. Простыми словами, фреймворк — это набор готовых инструментов, которые избавляют тебя от рутины. Не нужно самому писать вывод результатов или подсчитывать количество пройденных тестов. GoogleTest делает это за тебя.

В центре GoogleTest — макросы. Это специальные команды, которые проверяют условия и сообщают о результате. Главных три: EXPECT_EQ, EXPECT_TRUE, EXPECT_FALSE.

EXPECT_EQ(expected, actual) проверяет, что два значения равны. EXPECT_TRUE(condition) проверяет, что условие истинно. EXPECT_FALSE(condition) — что ложно. Например: ты написал функцию add(a, b). EXPECT_EQ(add(2, 3), 5) проверит, что она действительно возвращает 5.

Важный момент: есть два семейства макросов — EXPECT_* и ASSERT_*. Разница в поведении при ошибке. EXPECT — тест продолжается, даже если проверка не прошла. Это как предупреждение на приборной панели автомобиля: лампочка загорелась, но ехать можно. ASSERT — тест немедленно останавливается. Это стоп-кран: дальнейшая работа бессмысленна, потому что данные повреждены.

Минимальный тест на GoogleTest выглядит так:

#include <gtest/gtest.h>
#include "math_utils.h"

TEST(MathUtilsTest, AddPositiveNumbers) {
    EXPECT_EQ(add(2, 3), 5);
}

Макрос TEST() объявляет тест. Первый аргумент — имя тестового набора, второй — имя тестового случая. Внутри фигурных скобок — сами проверки.

3. Ставим GoogleTest через CMake FetchContent

Установка фреймворка — как подключение нового станка к конвейеру. Один раз правильно подсоединил провода, и дальше он работает без сбоев.

Нам понадобится CMake. Простыми словами, CMake — это инструмент, который говорит компилятору, из каких файлов собирать программу и какие библиотеки подключать. Ты описываешь структуру проекта в файле CMakeLists.txt, а CMake превращает это описание в инструкции для компилятора.

Раньше для подключения GoogleTest нужно было вручную скачивать репозиторий, собирать библиотеку, прописывать пути. Сейчас всё проще. Мы используем FetchContent. Простыми словами, FetchContent — это как автоматический курьер. Ты говоришь ему: «Привези GoogleTest версии 1.15.2 из этого репозитория», и он сам съездит, скачает и распакует библиотеку прямо в твой проект.

Создай структуру папок:

my_project/
├── CMakeLists.txt
├── src/
│   ├── math_utils.h
│   └── math_utils.cpp
└── tests/
    └── test_math_utils.cpp

Файл CMakeLists.txt в корне проекта:

cmake_minimum_required(VERSION 3.24)
project(MyProject)

# Подключаем GoogleTest через FetchContent
include(FetchContent)
FetchContent_Declare(
    googletest
    GIT_REPOSITORY https://github.com/google/googletest.git
    GIT_TAG v1.15.2
)
FetchContent_MakeAvailable(googletest)

# Включаем тестирование
enable_testing()

# Собираем исполняемый файл тестов
add_executable(tests tests/test_math_utils.cpp src/math_utils.cpp)
target_link_libraries(tests GTest::gtest_main)

# Автоматически находим и регистрируем тесты
include(GoogleTest)
gtest_discover_tests(tests)

Разберём ключевые строки. FetchContent_Declare говорит CMake, откуда скачать GoogleTest. FetchContent_MakeAvailable скачивает и делает библиотеку доступной. enable_testing() включает режим тестирования — без него ctest не увидит тесты. gtest_discover_tests автоматически находит все тесты в проекте, чтобы ты не регистрировал их вручную.

Три команды для сборки и запуска:

cmake -S . -B build      # конфигурируем сборку в папку build
cmake --build build       # собираем проект
ctest --test-dir build    # запускаем тесты

4. Твой первый тест: проверяем функцию сложения

Первый тест — как «Hello, world!» в тестировании. Важен сам факт запуска.

Напишем простую функцию сложения в math_utils.h:

// math_utils.h
int add(int a, int b);

И реализацию в math_utils.cpp:

// math_utils.cpp
#include "math_utils.h"

int add(int a, int b) {
    return a + b;
}

Теперь тесты в tests/test_math_utils.cpp:

#include <gtest/gtest.h>
#include "math_utils.h"

TEST(MathUtilsTest, AddPositiveNumbers) {
    EXPECT_EQ(add(2, 3), 5);
}

TEST(MathUtilsTest, AddNegativeNumbers) {
    EXPECT_EQ(add(-2, -3), -5);
}

TEST(MathUtilsTest, AddMixedNumbers) {
    EXPECT_EQ(add(-2, 3), 1);
}

Запускаем:

cmake -S . -B build
cmake --build build
ctest --test-dir build

Вывод зелёный: [ PASSED ] 3 tests. Отлично.

А теперь — важный шаг. Давай специально сломаем тест. Поменяем EXPECT_EQ(add(2, 3), 5) на EXPECT_EQ(add(2, 3), 99). Запускаем снова и видим красный вывод:

[  FAILED  ] MathUtilsTest.AddPositiveNumbers
Expected equality of these values:
  add(2, 3)
    Which is: 5
  99

Читай вывод сверху вниз. Первая строка — имя упавшего теста. Дальше — что ожидалось и что получилось на самом деле. «Which is: 5» — фактический результат функции. Ниже — ожидаемое значение (99). Они не совпали, поэтому тест красный. Теперь ты знаешь, где именно ошибка, и можешь её исправить. Красный вывод — это не страшно. Это подсказка.

5. Тестируем алгоритм: линейный поиск

Одно дело — проверить молоток на одном гвозде. Другое — убедиться, что он забьёт сотню разных гвоздей и не сломается на кривом.

В статье «Алгоритмы и структуры данных для начинающих: ваш первый шаг к эффективному коду» мы разбирали линейный поиск. Давай напишем для него тесты.

Функция linear_search принимает массив и искомое значение. Возвращает индекс элемента или -1, если элемент не найден:

#include <vector>

int linear_search(const std::vector<int>& arr, int target) {
    for (int i = 0; i < arr.size(); i++) {
        if (arr[i] == target) {
            return i;
        }
    }
    return -1;
}

Теперь напишем пять тестов — для разных сценариев:

TEST(SearchTest, ElementFound) {
    std::vector<int> arr = {10, 20, 30, 40, 50};
    EXPECT_EQ(linear_search(arr, 30), 2);
}

TEST(SearchTest, ElementNotFound) {
    std::vector<int> arr = {10, 20, 30};
    EXPECT_EQ(linear_search(arr, 99), -1);
}

TEST(SearchTest, EmptyArray) {
    std::vector<int> arr = {};
    EXPECT_EQ(linear_search(arr, 10), -1);
}

TEST(SearchTest, FirstElement) {
    std::vector<int> arr = {10, 20, 30};
    EXPECT_EQ(linear_search(arr, 10), 0);
}

TEST(SearchTest, LastElement) {
    std::vector<int> arr = {10, 20, 30};
    EXPECT_EQ(linear_search(arr, 30), 2);
}

Мы проверили обычный случай (элемент найден), случай отсутствия элемента, пустой массив, первый элемент и последний. Это граничные условия — крайние случаи, на которых код часто ломается. Если тестировать только «хорошие» данные, программа может упасть в реальной работе при пустом вводе или нулевом значении.

Линейный поиск и юнит-тесты

6. А как в других языках? Python, Java и C# (обзорно)

Автомобили разных марок устроены по-разному, но руль, педали и коробка передач работают по одному принципу. Так и с тестами. Освоив GoogleTest, ты узнаешь знакомые черты в любом другом фреймворке. Везде принцип AAA, везде есть макросы-проверки. Меняется только синтаксис.

Тестовые утверждения в разных языках

def add(a, b):
    return a + b

def test_add():
    assert add(2, 3) == 5

@Test
void addsTwoNumbers() {
    assertEquals(5, add(2, 3));
}

[Fact]
public void AddsTwoNumbers() {
    Assert.Equal(5, Add(2, 3));
}

7. Типичные ошибки

6 типичных ошибок в тестировании

8. Попробуй сам: три задания

9. Шпаргалка

10. Что дальше

Ты написал свой первый юнит-тест. Это важный шаг — ты перешёл от «код вроде работает» к «я могу это доказать». Но тесты проверяют только то, что ты явно запрограммировал. А что насчёт ошибок, о которых ты не подумал?

В следующей статье «Безопасность в разработке: основные уязвимости и как их избегать» ты научишься находить места в коде, которые могут сломать твою программу или дать доступ злоумышленнику, и закрывать их. С помощью тестов, которые ты освоил сегодня, ты сможешь проверить, что защита действительно работает. Например, напишешь тест, который убедится, что программа не падает и не выдаёт секретных данных при вводе некорректной строки.

Если хочешь увидеть общую картину и понять, как эта тема встраивается в твой путь к первой работе, загляни в хаб-статью «Путь начинающего разработчика: дорожная карта от нуля до первой работы». А если примеры на Python или C# показались тебе интереснее, чем C++, прочитай статью «Какой язык программирования выбрать для изучения новичку» — она поможет определиться.

Заключение

Юнит-тест — не страшный экзамен, а твой личный робот-проверяльщик. Он берёт рутину на себя и освобождает тебе время для настоящего творчества — написания нового кода. Ты уже знаешь, как писать функции на C++, как собирать проект с CMake и как запускать тесты через ctest. Выполни три задания из «Попробуй сам», чтобы рука запомнила макросы EXPECT и ASSERT. Начни с первого теста. Он уже ждёт тебя.