ИИ в тестировании пишет «зелёные пустышки»: как за 15 минут отсеять ложные проверки

Автотесты от ИИ проходят с покрытием 100%, но пропускают баги в продакшене: Сергей Прощаев, Tech Lead в финтехе и преподаватель ОТУС, разбирает на четырёх примерах Java-кода, как отличить настоящую проверку от зелёной пустышки.

Проблема знакома каждому, кто хотя бы раз просил ИИ написать юнит-тесты. Сергей Прощаев, Tech Lead и руководитель направления Java/Kotlin-разработки в финтехе и электронной коммерции, преподаватель курсов разработки и архитектуры в ОТУС, описывает типичную ситуацию: вы отдали класс ИИ-агенту, получили больше сорока тест-методов, покрытие по строкам показало 100%, CI (система непрерывной интеграции, автоматически проверяющая код перед слиянием) доволен. Но часть тестов бесполезна, а некоторые закрепляют неправильную логику.

Ниже разберём, как за несколько минут на ревью отсеять пустышки от реальных проверок. Все примеры на Java, но принцип работает для любого языка.

Что понадобится

• Любая IDE с поддержкой Java (IntelliJ IDEA, Eclipse, VS Code с плагином)
• JUnit 5 (фреймворк для юнит-тестирования на Java)
• Класс с бизнес-логикой, на который ИИ уже сгенерировал тесты
• 15-20 минут на разбор и практику

Как проверять ИИ-тесты: пошаговая инструкция

1. Задайте ИИ-агенту задачу на генерацию тестов. Опишите класс и метод, который нужно покрыть. Для примера возьмём сервис скидок: если сумма заказа больше 100, скидка 10%; если товаров больше 5, скидка 5%. Правила не суммируются: применяется только большая.

public class DiscountService {
    private static final BigDecimal THRESHOLD = new BigDecimal("100");
    private static final BigDecimal RATE_LARGE_SUM = new BigDecimal("0.10");
    private static final BigDecimal RATE_MANY_ITEMS = new BigDecimal("0.05");

    public BigDecimal applyDiscount(BigDecimal total, int itemCount) {
        if (total == null) {
            throw new IllegalArgumentException("total is null");
        }
        BigDecimal discount = BigDecimal.ZERO;
        if (total.compareTo(THRESHOLD) > 0) {
            discount = RATE_LARGE_SUM;
        }
        if (itemCount > 5 && discount.compareTo(RATE_MANY_ITEMS) < 0) {
            discount = RATE_MANY_ITEMS;
        }
        return total.subtract(total.multiply(discount));
    }
}

1. Получите тесты и не смотрите на статус. ИИ выдаст десятки методов, все зелёные. Главная ловушка: одобрить набор, доверившись зелёному статусу, не разобрав, что именно проверяет каждый assert (утверждение, которое должно «упасть» при неправильном результате).

2. Задайте каждому тесту один вопрос: если я сломаю логику метода, этот тест упадёт? Тест, который проходит при любом поведении кода, не различает правильный и неправильный результат. Он добавляет стоимость поддержки и ложную уверенность, не более.

3. Проверьте тест на «пустой assert». Вот характерный пример пустышки:

@Test
void testApplyDiscount() {
    BigDecimal result = discountService.applyDiscount(
        new BigDecimal("200"), 3);
    assertNotNull(result);
}

Единственная проверка тут assertNotNull(result). Она пройдёт при любом ненулевом результате: неправильная скидка, нулевая скидка, отрицательное число. Для бизнес-логики это имитация проверки, а не сама проверка. При этом assertNotNull не зло сам по себе: для фабрик, методов с Optional, создания сессий он законен. Проблема в том, что здесь это единственный assert.

1. Проверьте, не дублирует ли тест саму логику метода. Второй частый паттерн:

@Test
void testDiscountForLargeOrder() {
    BigDecimal total = new BigDecimal("200");
    int itemCount = 3;
    BigDecimal expected = total.subtract(
        total.multiply(new BigDecimal("0.10")));
    BigDecimal result = discountService.applyDiscount(total, itemCount);
    assertEquals(expected, result);
}

На первый взгляд тест выглядит правильно: есть assertEquals, есть конкретные числа. Но expected вычисляется по той же формуле, что и сам метод. Если в методе ошибка в расчёте, тест повторит её и останется зелёным. Ожидаемое значение должно быть жёстко зашито числом, а не пересчитано.

1. Проверьте граничные значения на точность ожидания. Третий тест:

@Test
void testDiscountBoundary() {
    BigDecimal result = discountService.applyDiscount(
        new BigDecimal("100"), 3);
    assertEquals(new BigDecimal("100"), result);
}

Сумма ровно 100, товаров 3. По логике класса скидка не применяется (порог строго больше 100). Тест ожидает 100 и проходит. Этот тест полезнее предыдущих двух: он проверяет граничное условие с жёстко зашитым значением. Но при ревью стоит убедиться, что рядом есть тест на 100.01, иначе пограничный случай покрыт только с одной стороны.

1. Проверьте, не тестирует ли assert несуществующую логику. Четвёртый тест:

@Test
void testBothDiscountsApply() {
    BigDecimal total = new BigDecimal("200");
    int itemCount = 10;
    BigDecimal expected = total.subtract(
        total.multiply(new BigDecimal("0.15")));
    BigDecimal result = discountService.applyDiscount(total, itemCount);
    assertEquals(expected, result);
}

По спецификации скидки не суммируются: применяется только большая. Но тест ожидает скидку 15% (10% + 5%). Этот тест не просто бесполезен. Он закрепляет неправильную логику. Если тест зелёный, значит, метод содержит баг. Если красный, ИИ-агент сгенерировал тест, который противоречит спецификации. В обоих случаях без знания бизнес-правил вы этого не увидите.

1. Сформулируйте правило для будущих ревью. Перед апрувом каждого ИИ-теста проверяйте три вещи:
2. Assert проверяет конкретное жёстко зашитое значение, а не пересчитанное по той же формуле
3. Тест способен упасть при реалистичной поломке логики
4. Ожидаемый результат соответствует спецификации, а не поведению кода «как есть»

Что с этого вам прямо сейчас?

Разработчику, который использует ИИ в тестировании. После каждой генерации тестов пройдите по чек-листу из шага 8. Это занимает 10-15 минут на 30-40 тестов и отсеивает до половины пустышек. В проде будет меньше сюрпризов.

Автору Дзена, который пишет про технологии. Тема ИИ в тестировании актуальна для аудитории разработчиков. Разборы конкретных ловушек с примерами кода собирают вовлечение лучше, чем общие рассуждения о «пользе нейросетей».

Тимлиду и руководителю. Добавьте в чек-лист код-ревью пункт о проверке assert-ов в ИИ-сгенерированных тестах. По опыту Сергея Прощаева, такие тесты попадаются на ревью буквально каждую неделю.

Начинающему разработчику. Навык, который вы тренируете, разбирая эти четыре теста, называется «критическое чтение тестов». Он отделяет человека, который умеет работать с ИИ-агентом, от человека, который принимает любой результат.

Главный вывод из разбора Сергея Прощаева: зелёный пайплайн не гарантия качества, а лишь сигнал, что код выполнился. Настоящая защита начинается с вопроса, который ИИ пока не задаёт сам: «А что будет, если я сломаю этот метод?». Пока вы задаёте этот вопрос за него, ваш код в безопасности.