Регрессионное тестирование (Regression Testing)

Регрессионное тестирование — это практика повторного запуска набора существующих тестов после внесения изменения в код, специально для того, чтобы поймать «регрессии» — случаи, когда ранее работавшая функциональность ломается как непреднамеренный побочный эффект изменения, задуманного совсем для другой цели. Название отличает его от тестирования новой функциональности: регрессионное тестирование про проверку того, что старое поведение всё ещё сохраняется, а не про валидацию нового поведения. На практике регрессионное тестирование в основном автоматизировано через те же наборы тестов, которые используются для других целей (юнит-, интеграционные и end-to-end тесты — все они одновременно служат страховочной сетью от регрессий при запуске на каждое изменение), а не являются полностью отдельной категорией тестов со своими выделенными тест-кейсами, хотя некоторые команды всё же поддерживают специальный «регрессионный набор», нацеленный на исторически хрупкие участки кодовой базы. Почему это важно для разработчиков AI/SaaS: по мере роста кодовой базы растёт и риск того, что не связанное изменение случайно сломает что-то далеко в системе — общая вспомогательная функция, используемая в двенадцати местах, миграция базы данных, меняющая поведение столбца, обновление зависимости с тонким breaking change. Всеобъемлющий, быстрый регрессионный набор, автоматически запускаемый в CI на каждое изменение, — это то, что делает безопасным продолжать быстро выпускать изменения по мере роста площади кодовой базы, вместо того чтобы каждое изменение требовало исчерпывающего ручного перетестирования всего продукта. Это особенно важно для разработки, управляемой ИИ-агентами: агенту, которому поручено «добавить функцию X», нужен регрессионный набор как эталон истины, чтобы подтвердить, что он незаметно не сломал функцию Y, реализуя X. Как это работает: регрессионные тесты обычно представляют собой накопленный за время жизни проекта массив юнит-, интеграционных и end-to-end тестов, выполняемых как полный набор (или как разумно выбранное релевантное подмножество в больших кодовых базах с инструментами анализа влияния тестов) при каждом pull request через CI. Проваленный регрессионный тест блокирует слияние, пока либо не будет исправлен код, либо не будет обновлён сам тест (если старое поведение было намеренно изменено, а тест просто устарел). Практический пример: разработчик рефакторит общую вспомогательную функцию `formatCurrency()`, чтобы поддержать новую валюту, немного изменяя внутреннюю логику округления для производительности. CI автоматически запускает полный набор тестов на pull request; регрессионный тест, написанный месяцы назад для не связанной функции выставления счетов — `expect(formatCurrency(19.995, "USD")).toBe("$20.00")` — проваливается, потому что рефакторенная логика округления теперь возвращает `"$19.99"`. Без этого регрессионного теста изменение округления, вероятно, было бы выпущено незамеченным и вызвало бы реальные расхождения в выставлении счетов в production; вместо этого CI ловит это за считанные минуты, разработчик исправляет граничный случай округления, и исправление проверяется перед слиянием.