Минимальный набор тестов для кода, сгенерированного ИИ, который остаётся стабильным

Почему нестабильный код, сгенерированный ИИ, продолжает ломаться после исправления\n\nНестабильный код, сгенерированный ИИ, — это тот самый код, который вроде бы работает, пока вы его не трогаете. Вы фиксите одну ошибку — и ломаются два несвязанных экрана. Деплой, который вчера прошёл, сегодня падает. Небольшие изменения дают большие сюрпризы, потому что в коде есть скрытые побочные эффекты и неясные правила.\n\nВ реальных проектах это часто выглядит так:\n\n- Изменение логина ломает биллинг, потому что оба зависят от недоделанного хелпера.\n- Один ответ API меняет форму, и UI тихо уходит в пустые состояния.\n- Авторизация работает локально, но падает в проде из‑за пропавших переменных окружения или утёкших секретов.\n- Быстрая рефакторинг‑правка вызывает случайные падения, потому что состояние хранится не в том месте.\n\nЭто типично для прототипов, сгенерированных ИИ: код создаётся кусками, а не как система. Имена расходятся, временные хаки становятся зависимостями, и редко бывает страховочная сеть. Команды делают экстренные фиксы снова и снова. Это дорого и стрессово.\n\nСамый дешёвый способ остановить кровотечение — небольшой, но ценный набор тестов. Тесты не волшебство. Они просто ловят поломки рано, до того как их увидят пользователи. Они также дают уверенность рефакторить и убирать странные места без гаданий.\n\nТри типа тестов дают наибольшую защиту при минимальных усилиях:\n\n- Smoke-тесты: приложение вообще запускается?\n- API-контрактные тесты: ответы остаются совместимыми с UI и интеграциями?\n- Регрессионные тесты: не возвращается ли уже исправленная ошибка?\n\nЦель не 100% покрытие. Успех проще: вы можете деплоить без страха, менять код без ломания прошлых фикс, и упавший тест указывает на конкретную фичу, которая сломалась.\n\n## Что защитить в первую очередь (20% причинят 80% боли)\n\nЕсли ваше приложение сгенерировано инструментами ИИ, может казаться, что всё хрупко. Минимальный набор работает лучше всего, когда он защищает пути, которыми люди пользуются ежедневно, и места, где одно небольшое изменение может сломать пятёрку других вещей.\n\nНачните с перечисления пользовательских сценариев, которые вызывают больше всего запросов в поддержку при их падении. Будьте практичны: что реально делает продукт «вниз» для пользователя? Обычно это вход и регистрация (включая сброс пароля), оформление заказа или подписки, ваш основной поток создать‑изменить‑удалить, вебхуки и загрузка/скачивание файлов.\n\nЗатем посмотрите на интеграции, которые скорее всего сломаются странно: платежи, доставка почты, провайдеры идентификации и хранение файлов. Вам не нужно полное end‑to‑end покрытие. Нужны быстрые проверки, доказывающие, что вы всё ещё можете подключиться и получить вменяемый ответ.\n\nТеперь выберите только 3–5 эндпоинтов или потоков, которые не должны падать никогда. Для простого SaaS это может быть: вход, создание проекта, приглашение коллеги, отмена подписки.\n\nПеред тем как писать тест, определите, что значит «работает» для каждого из них. Держите определение коротким и измеримым:\n\n- Ожидаемый статус и пара ключевых полей\n- Форма ответа (ключи и типы)\n- Один ключевой побочный эффект (запись создана, письмо поставлено в очередь, вебхук отправлен)\n- Одно правило безопасности (нельзя получить данные другого пользователя)\n\nНаконец, выберите одно тестовое окружение и придерживайтесь его. Локально — ок, если настройка консистентна. Staging — тоже ок, если данные контролируются. Смешивание обоих превращает «минимальный» в запутанный шум.\n\n## Smoke‑тесты: быстрые проверки, которые ловят явные поломки\n\nSmoke‑тесты отвечают на один вопрос после любого изменения: приложение всё ещё стартует и самые важные пути отвечают?\n\nХороший smoke‑тест не пытается доказать, что всё правильно. Он доказывает, что базовые вещи не сломались полностью. Поэтому smoke‑тесты — отличный первый слой для шатких, сгенерированных ИИ проектов.\n\n### Что включать\n\nВыберите несколько целей, которые означают «приложение живо» и «пользователь может сделать главное действие». Например:\n\n- Хелсчек возвращает 200 (или загружается главная страница)\n- Страница входа рендерится (или авторизационный эндпоинт отвечает)\n- Один ключевой API‑вызов возвращает ожидаемый статус (например, получение текущего пользователя или основной список)\n- Соединение с базой данных открывается (только если это частая причина падений)\n\nДержите каждый тест коротким. Цель — одна ясная проверка на тест, например «вернул 200» или «в ответе есть userId». Когда smoke‑тест падает, причина должна быть очевидной.\n\n### Как сделать их быстрыми и надёжными\n\nЗадайте твёрдый лимит: менее 1–2 минут в сумме. Smoke‑тесты должны запускаться постоянно, а не «когда кто‑то вспомнит». Простая рутина работает хорошо:\n\n- Запускайте smoke‑тесты локально перед пушем\n- Запускайте автоматически на каждом pull request\n- Блокируйте слияние, если они падают\n\nПример: вы починили авторизацию, которая случайно возвращала 500. Добавьте smoke‑тест, который логинится тестовым аккаунтом, а затем вызывает GET /me. Если это снова сломается, вы узнаете немедленно.\n\n## API‑контрактные тесты: держите ответы стабильными для UI и интеграций\n\nКонтрактные тесты проверяют, что эндпоинт держит обещание: какие поля приходят, какие у них типы и какой формат ошибок клиент может ожидать. Они не проверяют каждое правило бизнес‑логики. Они предотвращают одну из самых распространённых проблем в быстро меняющемся коде: бэкенд меняет форму ответа и UI молча ломается.\n\nДля минимального набора выберите только те эндпоинты, чьи изменения сильно навредят. Обычно это несколько вызовов, которые UI делает на каждой загрузке страницы, плюс всё, что зависит внешний партнёр.\n\nПростой способ выбрать — посмотрите network вкладку и логи ошибок, затем зафиксируйте 2–3 критичных эндпоинта, например:\n\n- Логин или проверка сессии (am I signed in?)\n- Профиль текущего пользователя (who am I?)\n- Основное действие создания (create order, save draft, post message)\n- Критический список (my projects, my invoices)\n\nПокрывайте и успешные, и ошибочные сценарии. Многие нестабильные приложения падают на скучных путях: пропавшие заголовки авторизации, некорректный ввод, истёкшие сессии.\n\n### Что проверять (и что игнорировать)\n\nФиксируйте только стабильные части. Проверяйте то, с чем человек может согласиться. Пропускайте изменчивые поля, которые меняются при каждом запуске.\n\n- Обязательные поля существуют (id, email, status) и их типы имеют смысл\n- Ошибки всегда имеют одну форму (code, message) и корректный HTTP‑статус\n- Массивы всегда массивы, а не null\n- Игнорируйте временные метки, случайные ID и порядок, если порядок не часть обещания\n\nПишите ожидания простым языком, чтобы нетехнический основатель мог их проверить. Пример: «Если нет авторизации, /me возвращает 401 с { code, message }. Если авторизация валидна, возвращает 200 с { id, email }.» Это одно правило предотвращает много переделок.\n\n## Регрессионные тесты: превратите фиксы в постоянную защиту\n\nРегрессионные тесты — это «эта ошибка никогда не должна вернуться» тесты. В кодовых базах, сгенерированных ИИ, фиксы могут исчезнуть при следующей генерации файла или рефакторинге. Небольшой регрессионный набор делает ваши фиксы стойкими.\n\nЛучший момент добавить регрессионный тест — сразу после фикса, пока воспроизведение ещё свежо. Спустя недели вы забудете точные входные данные и реальное влияние на пользователя.\n\nДержите каждый регрессионный тест сфокусированным на минимальном воспроизведении. Захватите только то, что нужно: конкретные входные данные, несколько шагов, которые вызывают баг, и ожидаемый результат. Если старый баг требовал десять экранов настройки, это сигнал, что нужен лучший тест‑син — а не огромный тест.\n\nПростой паттерн:\n\n- Воссоздайте старый падающий запрос или действие в тесте.\n- Ассертом зафиксируйте то неправильное поведение, которое раньше наблюдалось (код статуса, сообщение об ошибке, неверные данные).\n- Примените фикс.\n- Обновите ожидание на корректное поведение и оставьте его точным.\n- Назовите тест так, чтобы будущий вы понял, почему его нельзя ломать.\n\nИмена тестов — недооценённая документация. Хорошее имя включает, что ломалось и почему это важно, например: rejects_login_when_token_is_missing_prevents_account_takeover.\n\nКонкретный пример: вы исправили баг сброса пароля, который раскрывал, существует ли пользователь. Регрессионный тест должен отправить reset‑запрос для несуществующего email и убедиться, что ответ остаётся общим и последовательным.\n\n## Пошагово: соберите минимальный набор за одну сфокусированную сессию\n\nСделайте тесты простыми для поиска и скучными для запуска. Создайте небольшую структуру и правило именования, которые вы будете использовать через месяц:\n\n- tests/smoke/ для проверок «вообще запускается?»\n- tests/contracts/ для проверки формы ответов API\n- tests/regression/ для багов, которые вы уже починили\n\nДальше добавьте горстку тестов, которые дадут быстрое доверие. Держите setup простым, чтобы они запускались одинаково на каждой машине. Хорошая отправная точка:\n\n- 3 smoke‑теста (загрузка, один главный поток, один критический API)\n- 2 контрактных теста (два самых используемых эндпоинта)\n- 2 регрессионных теста (последние два реальных инцидента)\n\nКогда пишете smoke‑тесты, думайте как усталый пользователь: «я открываю приложение, делаю главное действие, оно работает». Когда пишете контрактные тесты — думайте как фронтенд: «мне нужны id, name и role, а не неожиданное переименование». Когда пишете регрессионные тесты — копируйте точные шаги, которые ломали в продакшне, и затем утверждайте исправленное поведение.\n\nЗапустите всё локально сначала, затем ту же команду в пайплайне деплоя. Если тесты слишком медленные — сокращайте охват, а не точность.\n\nОдно правило поддерживает живость набора: если вы трогаете фичу, вы добавляете или обновляете тест для неё.\n\n## Сделайте тесты надёжными: стабильные данные, стабильный setup, стабильный cleanup\n\nМинимальный набор полезен только если он даёт одинаковый ответ при каждом запуске. Большинство «случайных падений» не случайны. Они вызваны общими данными, непоследовательным setup или тестами, которые зависят от внешних сервисов.\n\nДержите тестовые данные отдельно от реальных. Используйте тестовую базу, временную схему или одноразовый набор данных, который можно безопасно подчистить. Если тесты могут повредить продовые данные, они в конце концов их испортят или станут слишком страшными для запуска.\n\nСделайте setup предсказуемым. Создайте несколько известных пользователей и ролей и переиспользуйте их: админ, обычный пользователь и заблокированный пользователь. Зафиксируйте их креды в конфиге тестов, чтобы не гоняться за изменениями позже.\n\nВнешние сервисы — частая причина флейки. Если тесты бьют реальные email, платёжные или вебхук сервисы, вы получите таймауты, лимиты и неожиданные падения. Подменяйте такие вызовы, где можно, или стабуйте их так, чтобы тест проверял «мы отправили правильный запрос» и «мы обработали ответ».\n\nФикстуры помогают избежать копипасты данных, которые со временем дрейфуют. Держите небольшой набор билдеров для общих объектов: пользователь, проект, заказ. Используйте понятные дефолты и переопределяйте только то, что нужно тесту.\n\nСбрасывайте состояние между тестами, чтобы одно падение не отравляло следущий. Простой цикл: создайте данные, выполните действие, проверьте важное, затем очистите (rollback или truncate таблиц) и сбросьте кэши/флаги.\n\n## Частые ошибки, которые тратят время и создают флейки\n\nСамый быстрый способ потерять тесты — пытаться охватить всё сразу. Если в первый день вы добиваетесь полного покрытия, вы застрянете в настройке, будете бороться с падениями и никогда не выпустите рабочий набор.\n\nЕщё одна ловушка — тестировать не то. Пиксель‑перфектные UI‑проверки и точное совпадение текста успокаивают, но ломаются при безобидных изменениях вроде новой подписи кнопки. Минимальные тесты должны фокусироваться на результатах: «пользователь может войти», «итог счёта правильный», «API возвращает поля, нужные UI».\n\nТесты становятся флейки, когда они зависят от интернета. Реальные платежи, email или аналитика падают, получают лимиты или меняют ответы. Стабуйте сторонние сервисы и оставляйте одну периодическую end‑to‑end проверку для staging, а не на каждый коммит.\n\nСледите за хрупкими утверждениями. ID, временные метки и автоматически сгенерированные сообщения постоянно меняются в беспорядочных прототипах. Предпочитайте стабильные проверки: коды статусов, ключевые поля и простые шаблоны (например, «createdAt существует и это ISO‑дата»), вместо точного совпадения строки временной метки.\n\nЕсли вы боретесь с флейком, эти исправления обычно помогают быстро:\n\n- Тестируйте результаты, а не пиксели UI или точные формулировки\n- Стабуйте внешние API и контролируйте ответы\n- Избегайте ассертов по случайным ID и точным временным меткам\n- Добавьте хотя бы один «путь ошибки» на критичный эндпоинт\n- Держите набор быстрым (минуты, не десятки минут)\n\nНе игнорируйте ошибочные пути. Прототипы, созданные ИИ, часто ломаются на истёкших сессиях, пропавших переменных окружения и некорректных полезных нагрузках. Если вы тестируете только счастливые пути, вы будете снова ломать «починенные» фичи.\n\n## Быстрая чек‑лист: защищает ли ваш минимальный набор свою цель?\n\nМинимальный набор остаётся минимальным только если он защищает то, что вы деплоите, и остаётся быстрым для запуска.\n\n### Набор защищает базовые вещи\n\nЕсли хоть один из пунктов падает, приложение небезопасно для деплоя:\n\n- Приложение стартует чисто (нет пропавших переменных, нет краша при boot).\n- Настройка базы данных работает (миграции проходят на чистой базе).\n- Одна ключевая страница или экран рендерится (обычно дэшборд).\n- Топ‑3 API возвращают поля, которые реально нужны UI (имена и типы, которые вы используете).\n- Эти же API возвращают согласованные формы ошибок (чтобы UI мог показать понятное сообщение).\n\n### Набор остаётся простым в запуске и надёжным\n\nСкорость и повторяемость важнее объёма:\n\n- Последние два критичных бага, которые вы починили, имеют регрессионные тесты.\n- Тесты заканчиваются за пару минут на обычном ноутбуке.\n- Один человек может запустить всё одной командой, без tribal knowledge.\n\nКогда тест падает, вы должны сразу что‑то понять. Хороший фейл указывает на одну вероятную причину («отсутствует токен логина», «поле API переименовано»), а не на расплывчатый таймаут.\n\n## Пример: защитить починенную авторизацию от повторного ломания\n\nТипичная история: основатель деплоит прототип, сгенерированный ИИ, с логином и подписками. Всё работает в демо, но реальные пользователи сталкиваются с странными сбоями. Логины возвращаются на экран входа, сессии мгновенно истекают, и чекаут падает, потому что приложение считает, что пользователь вышел.\n\nКто‑то чинит логику авторизации, чистит cookie или токены, и сессия наконец держится. Через две недели маленькое изменение (часто в другой части кода) ломает вход снова. Никто не трогал «auth», но новый middleware, рефактор или tweak окружения изменил поведение.\n\nМинимальный набор предотвращает этот откат, поставив три маленькие защиты вокруг потока:\n\n- Smoke‑тест, который бьёт по маршруту входа и проверяет явный сигнал успеха (200 OK плюс наличие session cookie или токена).\n- Контрактный тест, который проверяет форму ответа сессии (например: user id, email, subscriptionStatus), чтобы UI не ломался при переименовании полей.\n- Регрессионный тест, который воспроизводит точную проблему, которую вы видели, например: «после входа GET /me возвращал 401» или «обновление страницы теряло сессию».\n\nДержите проверки простыми. Вы не пытаетесь тестировать каждый крайний случай. Вы защищаете то, что приносит деньги: люди могут войти и оставаться в системе.\n\nПлатёж окупается в следующий раз, когда кто‑то что‑то меняет: вместо того чтобы пользователи писали «не могу зайти», сборка падает с сообщением типа «в ответе сессии нет subscriptionStatus». Это пятиминутный фикс, а не многодневная паника.\n\nЭто также сокращает обсуждения с подрядчиками и агентствами. Больше не нужно спорить, работает ли auth на чьей‑то машине — тест выступает арбитром.\n\n## Следующие шаги: держите набор минимальным и продолжайте спокойно деплоить\n\nМинимальный набор работает только если он привязан к реальной боли. Цель не «больше покрытия». Цель — меньше сюрпризов после каждого изменения.\n\nВыберите следующие пять тестов, исходя из того, что реально стоило вам времени: тикеты в поддержку, простои и части приложения, которых вы боитесь. Вытяните последние три продовые ошибки (или почти‑падения) и превратите каждую в регрессионный тест, который падает так же, как упало в жизни.\n\nЧтобы не потерять темп и не дать тестам захватить вам неделю:\n\n- После каждого фикса добавляйте 1 маленький регрессионный тест, который гарантирует, что фикс держится.\n- После каждого инцидента добавляйте 1 smoke‑тест, который бы его быстро поймал.\n- Каждые пару недель добавляйте 1 контрактный тест для вашего самого используемого эндпоинта или интеграции.\n- Ведите короткий список «топ‑точек ломки» и удаляйте тесты, которые больше не соответствуют текущим рискам.\n- Остановитесь, когда новые тесты перестанут ловить реальные проблемы — это ваш текущий минимальный набор.\n\nЕсли кодовая база дикая, быстрое расширение тестов может обернуться против вас. Когда setup непредсказуем, вы получите флейки и люди перестанут верить набору. В этом случае сделайте короткий стабилизационный проход: обеспечьте один чистый путь для запуска приложения, настройте надёжную тестовую базу и уберите очевидные подводные камни вроде открытых секретов или хрупкого глобального состояния.\n\nЕсли вы унаследовали прототип, сгенерированный ИИ, который постоянно регрессирует, FixMyMess (fixmymess.ai) специализируется на диагностике и ремонте таких кодовых баз, затем добавляет ровно столько smoke-, контрактных и регрессионных тестов, чтобы фиксы не разваливались при следующем изменении.\n\nОтноситесь к вашему набору как к ремню безопасности: маленький, постоянно включённый и направленный на те аварии, которые уже случались.