Cursor пишет вам unit‑тесты за минуту. 5 паттернов, на которых эти тесты пропустят любой баг

Cursor пишет тесты быстро. Открыл класс, нажал Ctrl+I, кинул промпт «напиши unit‑тесты» — через минуту в файле сорок строк с моками, ассертами и красивыми именами вроде shouldReturnUserWhenIdIsValid. Прогнал — зелёные. Закоммитил, замержил, побежал дальше. Покрытие в проекте растёт, скорость написания тестов раза в три‑четыре выше, чем руками.

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

Ниже — пять типичных паттернов вайбкодинга unit‑тестов, которые сейчас встречаются практически в каждом проекте, где разработчики делегируют тесты Cursor, Copilot или Claude. Примеры на Java с JUnit и Mockito, но в pytest и Jest картина один в один.

Cursor пишет один happy‑path тест и считает работу выполненной

@Test
void shouldDivideTwoNumbers() {
    assertEquals(2, calculator.divide(10, 5));
}

Один тест на счастливый путь, и на этом Cursor останавливается — никаких проверок «что, если делитель ноль», «что, если переполнение int», «что, если оба значения отрицательные». Сделал ровно то, что просили: «напиши тест для метода divide», метод делит два числа — вот тест на деление двух чисел. От регрессий защита нулевая, можно сломать в divide вообще всё, кроме случая 10 / 5 = 2, и тест останется зелёным.

Лечится тем, что edge cases приходится проговаривать в промпте явно: «напиши тесты для divide, включая граничные случаи — деление на ноль, переполнение, отрицательные значения, ноль в делимом». После такой формулировки Cursor выдаёт уже три‑пять тестов вместо одного. Но просить нужно каждый раз, сам по дефолту edge cases часто не вспоминает, останавливается на самом простом сценарии.

Ассерт по строке там, где надо было по значению

assertEquals(
    "User created successfully",
    response.getMessage()
);

Cursor взял текущее значение из реализации и зафиксировал его в тесте. Через полгода продактам надоело «User created successfully», переименовали на «Пользователь зарегистрирован» и двести тестов краснеют разом, хотя в коде ничего не сломано.

Если в ассерте сравнивается строка, рядом должен быть комментарий о том, почему важна именно эта строка — контракт с фронтом, документация API, ещё какая‑то внешняя завязка. Если такого объяснения нет, проверять надо структуру, а не текст:

assertThat(response.getStatus()).isEqualTo(Status.CREATED);
assertThat(response.getUserId()).isNotNull();
assertThat(response.getCreatedAt()).isAfter(beforeTest);

Cursor про это правило не знает, и его надо явно прописывать либо в шаблоне промпта для каждой задачи, либо в системном промпте проекта (./cursor/rules или аналогичный конфиг).

Тест проверяет, что мок отдал то, что мок отдал

when(userRepository.findById(1L))
    .thenReturn(new User(1L, "Alice"));

User result = userService.getById(1L);

assertEquals("Alice", result.getName());

Этот тест проверяет ровно одно — что Mockito работает. Если внутри userService.getById написать return new User(1L, "Alice") напрямую, без обращения к репозиторию, тест останется зелёным. Сам же метод можно переписать в обход всей логики, и тест ничего не заметит.

Самый рабочий способ такие тесты выявлять — mutation testing. Идея очень простая: в тестируемый код вносятся мутации (+ меняется на -, < на <=, true на false), тесты прогоняются заново. Если мутация осталась живой, а тесты при этом зелёные — значит, они её не ловят, и реальной защиты в них нет. Для Java стандарт — PIT (pitest), для Python — mutmut, для JavaScript — Stryker. В PR с вайбкоженными тестами mutation score обычно болтается в районе 10–15%: то есть 85% потенциальных багов вносятся в код, а тесты их прозевают.

Mutation score ниже шестидесяти процентов — нормальный порог, после которого тесты идут на доработку, не доходя до мержа.

Cursor повторяет баг из кода прямо в ассерте

Cursor смотрит в код, видит, что метод делает X, и пишет тест, который ровно это X и подтверждает — даже если X на самом деле неправильное.

Допустим, в коде сидит такой баг:

if (price > 1000) {
    discount = price * 0.1;  // по ТЗ должно быть 0.15

Cursor читает реализацию, видит коэффициент 0.1, генерит тест:

@Test
void should10PercentDiscountForExpensive() {
    order.setPrice(2000);
    assertEquals(200, order.getDiscount());  // 200 = 10% от 2000
}

Тест зелёный, баг живёт в проде. Cursor посмотрел в код, увидел 0.1, написал тест ровно на 0.1. Имя теста — should10PercentDiscount — мимоходом цементирует баг: вот же, явно написано «должен быть 10%», всё работает по тестам, какие вопросы.

Профилактика — давать Cursor бизнес‑требования (спецификацию или ссылку на тикет с requirements), а не сам исходник, и просить написать тест по требованиям. Тогда у него есть с чем сверять код, и баг не уползает в тест автоматом. Для критической логики — платежи, скидки, расчёты по контрактам — это вообще должно быть железным правилом.

На замоканный сервис тест не ловит вообще ничего

@InjectMocks OrderService orderService;

@Mock OrderRepository repo;
@Mock PaymentService payments;
@Mock NotificationService notifications;
@Mock InventoryService inventory;
@Mock TaxCalculator tax;

@Test
void shouldCreateOrder() {
    when(repo.save(any())).thenReturn(new Order(1L));
    when(payments.charge(any())).thenReturn(true);
    when(inventory.reserve(any())).thenReturn(true);
    when(tax.calculate(any())).thenReturn(BigDecimal.TEN);

    Order result = orderService.create(buildRequest());

    assertNotNull(result);
}

В тесте замокано всё, и по факту проверяется одна строчка: что orderService.create возвращает не null. Любая логика между компонентами остаётся за бортом — поменяешь порядок вызовов в сервисе, удалишь вызов notifications.send, переставишь местами payments.charge и inventory.reserve, тест всё равно останется зелёным. Cursor такие тесты обожает: ничего сложного, никаких реальных баз, никаких контейнеров, никакого ожидания готовности, чистые моки.

Лучший фикс — там, где это уместно, перевести юнит‑тест на интеграционный с TestContainers и реальной Postgres, оставив моки только под внешние сервисы, которые недоступны в тестовом окружении. Cursor, кстати, с этим хорошо справляется: пишешь «перепиши этот юнит‑тест на интеграционный с TestContainers и реальной Postgres» — он переделывает за минуту. Проверить за ним надо только одно: чтобы замоканной не оказалась как раз та самая логика, которую тестом и хотите покрыть.

Итого

Чтобы вайбкодинг тестов реально работал, в процесс имеет смысл добавить две штуки. Первая — каждый PR с тестами от Cursor (или Copilot, или Claude в Cursor — без разницы) обязательно прогоняется через mutation testing. Mutation score меньше шестидесяти процентов — тесты на доработку. Вторая — на ревью к каждому тесту задаётся один вопрос: «Если в коде сделать баг X, этот тест его поймает?». Если ответ «нет» — тест либо переписывается, либо удаляется.

AI уже помогает писать тесты, генерировать кейсы и разбирать логи, но сам по себе он не делает тестирование надёжнее. Чтобы от него была польза, QA‑инженеру нужно понимать, где нейросеть ускоряет работу, а где начинает уверенно воспроизводить ошибки из кода, требований и моков.

На курсе «ИИ в тестировании: ускорение процессов и проверка ИИ‑функций» разберем, как применять AI‑инструменты в реальных QA‑процессах: от генерации тестовых сценариев и анализа дефектов до проверки функций, построенных на искусственном интеллекте.

Присмотритесь к бесплатным открытым урокам, которые проходят в рамках курса. Их проведут преподаватели‑практики: можно будет познакомиться с экспертами, протестировать формат обучения и задать вопросы.

2 июня в 20:00 — «Нейросети и глубокое обучение в тестировании ПО: как приручить ИИ».
_{Расскажем, как QA‑инженеры используют инструменты на базе ИИ для генерации тест‑кейсов, анализа логов, подготовки автотестов и автоматизации рутины.}
18 июня в 20:00 — «Тесты, которые чинят себя сами: практика ИИ в UI‑тестировании».
_{Покажем подходы к генерации тестов из пользовательских сценариев, семантические локаторы вместо XPath, computer‑use агентов и другие практики применения ИИ в UI‑тестировании.}

И подписывайтесь на канал OTUS в MAX — там публикуем анонсы открытых уроков, полезные материалы по IT‑направлениям и подборки для тех, кто хочет развиваться в профессии без лишнего инфошума.

推荐订阅源

Все публикации подряд на Хабре