Лекции

Разбираем, как выбрать самые «окупаемые» первые тесты в учебном C++‑проекте: почему начинать стоит с чистых функций (вход → выход), парсеров (строка → данные) и бизнес‑правил, а не с проверки печати в std::cout. Учимся отделять IO от логики, использовать быстрый старт через assert, и строить детерминированные проверки для функций вроде parse_int, parse_command, add_task и mark_done.

Разбираем, как сделать unit‑тесты читаемыми и расширяемыми с помощью структуры AAA ( Arrange → Act → Assert) и табличных (table‑driven) наборов кейсов. На примерах с std::optional<int>, парсером parse_amount() и разбором команды "add 250 lunch" учимся отделять подготовку данных от действия и проверок, избегать ловушек вроде value() на nullopt, и добавлять диагностику, чтобы сразу было видно, какой кейс упал.

Разбираем, как устроены автотесты в C++ с Catch2/doctest: зачем нужен тест‑фреймворк вместо assert, как работает test runner и почему у тестов «свой» main, как не получить «два main» или «ноль main», чем отличаются проверки CHECK и REQUIRE, как писать табличные тесты и добавлять контекст через INFO, а также как отделять “боевой” код от тестов на мини‑примере Expense Tracker.

Разбираем, зачем в CMake-проектах нужен CTest, даже если тесты уже написаны на doctest/ Catch2: что такое «тест как команда с exit-code», как подключить тестирование через enable_testing() и зарегистрировать тесты с add_test, как правильно запускать ctest из директории сборки, смотреть вывод при падении и фильтровать набор тестов по имени.

Разбираем, что такое CI (Continuous Integration) и почему его «язык» — это не YAML, а коды завершения процесса ( exit code): 0 для успеха и не‑ 0 для провала. Понимаем смысл трёх шагов configure → build → test на примере CMake/ CTest, собираем локальный мини‑пайплайн и разбираем типичные ошибки, из-за которых «локально прошло», а в CI — красное.