Что такое регрессионное тестирование (Regression Testing)?

Э, слушай, давай разберем эту тему, а то у меня уже волосы дыбом от того, как народ на проектах косячит. Регрессионное тестирование — это, по сути, твой спасательный круг, чтобы не обосраться с новыми фичами.

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

Зачем это, блядь, нужно? Да чтобы не было вот этого самого «ой, а мы и не думали, что это повлияет». Повлияет, сука, всегда! Особенно если архитектура у нас — хуй в пальто, а не монолит.

Как это делают, эти умники?

1. Полный регресс. Это когда запускаешь ВСЕ тесты, которые у тебя есть. Надежно? Ебать как! Долго? Овердохуища! Дорого? Да ты посмотри на счёт за облако! Делают обычно перед большим релизом, когда уже страшно просрать всё.
2. Выборочный регресс. А вот это уже для хитрожопых. Смотришь, что ты менял, и запускаешь только тесты, которые касаются этих модулей и того, что с ними связано. Быстро, но нужно иметь голову на плечах, чтобы понять, что за что цепляется. Иначе пропустишь регрессию, и будет пиздец.
3. Автоматизация в CI/CD. А это, дружок, мечта. Ты закоммитил код — и поехала малина: сама запустилась куча тестов, сама проверила, не сломалось ли старое. Красота! Правда, чтобы это настроить, нужно сначала нехило так попотеть.

Давай на живом примере, а то я чувствую, ты уже засыпаешь. Был у нас скрипт расчёта скидки, простой как три копейки.

# Была функция — святая святых (discount.py)
def calculate_discount(price, is_member=False):
    """Даёт 10% скидку своим, остальным — похуй."""
    if is_member:
        return price * 0.9
    return price

И на неё были тесты, которые свято верили, что мир справедлив.

# Старый добрый тест (test_discount.py)
def test_calculate_discount_basic():
    # Этот тест — наш регрессионный страж. Он должен проходить ВСЕГДА.
    assert calculate_discount(100) == 100  # Чужакам плати полную
    assert calculate_discount(100, is_member=True) == 90  # Своим — со скидкой

И вот приходит менеджер и говорит: «А давайте добавим ещё купоны, «SAVE5» на 5%». Ну, добавили, сука.

# Новая, улучшенная функция (discount.py)
def calculate_discount_v2(price, is_member=False, coupon_code=None):
    """Теперь тут скидка для своих И купон. Математика, блядь!"""
    final_price = price
    if is_member:
        final_price *= 0.9
    if coupon_code == "SAVE5":
        final_price *= 0.95
    return final_price

И вот тут-то и наступает момент истины, ёперный театр! Первым делом, блядь, не бежим показывать фичу, а запускаем наш старый тест! Адаптируем его, конечно, под новую функцию.

# Тот же страж, но для нового мира
def test_calculate_discount_regression():
    # Смотри, сука, главное: старая логика должна работать!
    # Никаких сюрпризов для старых клиентов.
    assert calculate_discount_v2(100) == 100  # Всё ещё 100 для чужаков
    assert calculate_discount_v2(100, is_member=True) == 90  # Всё ещё 90 для своих
    # А теперь проверяем новую фичу
    assert calculate_discount_v2(100, coupon_code="SAVE5") == 95  # 5% с купона
    # И комбо, мать его!
    assert calculate_discount_v2(100, is_member=True, coupon_code="SAVE5") == 85.5  # 100*0.9*0.95

Видишь? Если старые ассерты проходят — мы молодцы, не сломали прошлое. Если проходят новые — мы вдвойне молодцы, добавили будущее. А если что-то пошло не так — терпения ноль ебать, но мы узнали об этом сразу, а не от разъярённых пользователей.

Как это встроить в работу, чтобы не было мучительно больно?

1. Перед коммитом. Сам, как разработчик, запускаешь тесты, которые касаются твоего кода. Это как помыть руки после туалета — базовое правило.
2. В CI-пайплайне. Это уже система. Ты закинул код — она сама прогнала кучу проверок. Не прошёл — не пускает дальше. Идеально.
3. Перед выкаткой. Тут уже полный регресс на тестовом стенде, который как две капли воды похож на боевой. Последний рубеж.

Инструменты? Да любые, блядь! pytest, JUnit, Selenium — что душе угодно. Главное — автоматизировать эту рутину, чтобы не полагаться на «ой, да я вроде проверил». Потому что «вроде» — это самый дорогой на проекте специалист, он всегда приводит к «вротберунчик, всё упало».