Автотесты для новичков: зачем, что и как тестировать

Ты попросил Claude написать новую фичу для «Змейки» — например, магазин скинов или офлайн-режим. Код появился за минуту, приложение запускается, но через пару ходов змейка врезается в стену там, где раньше проходила. Или счёт рекорда сохраняется не тому игроку. Или после покупки скина игра вообще перестаёт реагировать на клавиши. Исправить одно легко, но починка ломает другое — классическая история. Автотесты решают эту проблему: они проверяют важные поведения автоматически, пока ты ещё не ушёл пить кофе.

Что такое автотест простыми словами

Автотест — это небольшая программа, которая запускает твою игру и проверяет, что всё работает так, как задумано. Если проверка не проходит, тест сообщает, что именно сломалось.

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

Тесты бывают разных уровней:

• Юнит-тесты проверяют отдельные функции. Например, функцию calculateScore(level, apples) — подаёшь на вход уровень и количество яблок, получаешь ожидаемое число очков.
• Интеграционные тесты проверяют, как функции работают вместе. Например, что после вызова buySkin() баланс монет уменьшается и выбранный скин попадает в localStorage.
• End-to-end тесты, или E2E, имитируют реального пользователя: открывают страницу, нажимают кнопки, двигают змейку и проверяют, что на экране происходит то, что должно.

В курсе «Собери своё первое приложение с ИИ» в модуле 4 к «Змейке» подключается именно такой набор. Всего получается 34 автотеста. Они не делают игру идеальной, но защищают от типичных регрессий — ситуаций, когда новая правка ломает то, что работало.

Зачем тесты, если код пишет ИИ

Это самый популярный вопрос. Раз Claude умеет генерировать код, почему бы просто не попросить его «не ломать ничего»?

Во-первых, ИИ не обладает полным контекстом твоего проекта. Он видит текущий файл и часть соседних, но не помнит каждое решение, которое ты принимал три дня назад. Поэтому «маленькое исправление» может нарушить старую договорённость — например, формат хранения рекорда в localStorage.

Во-вторых, скорость опасна. ИИ выдаёт рабочий код за секунды, и искушение сразу нажать «принять» велико. Без тестов ты узнаёшь о проблеме только тогда, когда сам столкнёшься с багом в игре.

В-третьих, тесты — это документация поведения. Когда через месяц ты вернёшься к коду и увидишь функцию snakeCanMoveTo(x, y), не придётся вспоминать, что она должна возвращать. Достаточно посмотреть тесты: они покажут, какие случаи считаются допустимыми, а какие — нет.

Наконец, тесты экономят нервы при добавлении фич. Хочешь ввести новый бонус или изменить скорость змейки? Запускаешь тесты — если всё зелёное, вероятность поломок резко падает. Если что-то красное, ты узнаёшь об этом до того, как пользователь увидит баг.

Что тестировать в «Змейке»

Не всё подряд. Начинай с того, что ломается чаще всего и болезненнее всего для игрока.

Движение и столкновения

Самое важное в змейке — правила передвижения. Проверяй:

• змейка растёт, когда съедает яблоко;
• змейка умирает при столкновении со стеной;
• змейка умирает при столкновении с собственным хвостом;
• змейка не может резко развернуться на 180 градусов (например, двигаться влево, если сейчас идёт вправо).

Эти правила легко нарушить одной неосторожной правкой в обработчике клавиш.

Состояние игры

Проверяй переходы между состояниями:

• игра начинается в правильном начальном состоянии;
• появляется экран «Game Over» при проигрыше;
• счёт обнуляется при новой игре;
• пауза реально останавливает движение.

Сохранение данных

В «Змейке» используется localStorage для рекорда. Тестируй:

• рекорд сохраняется, когда текущий счёт его превышает;
• рекорд не теряется после перезагрузки страницы;
• при отсутствии сохранённых данных игра не падает, а использует начальное значение.

Магазин и скины

Если в игре есть магазин, важно проверить:

• покупка списывает правильное количество монет;
• нельзя купить скин, который уже куплен;
• нельзя купить скин, если не хватает монет;
• выбранный скин применяется к отображению змейки.

Звук и PWA

Эти области сложнее тестировать в изоляции, но некоторые проверки возможны:

• звук включается и выключается по кнопке;
• приложение можно установить как PWA и оно загружается офлайн;
• кеш service worker не мешает обновлениям.

Не пытайся покрыть тестами каждую строчку кода. Цель — защитить ключевые сценарии, от которых зависит опыт игрока.

Какие тесты выбрать новичку

Для браузерной игры на JavaScript обычно используют два инструмента:

• Jest — для юнит- и интеграционных тестов чистых функций.
• Playwright или Cypress — для E2E-тестов, которые запускают браузер и имитируют пользователя.

В курсе фокус на практике, а не на настройке. Поэтому ИИ-ассистент помогает подключить тестовый фреймворк и написать первые проверки. Тебе не нужно знать Jest или Playwright в деталях — достаточно понимать, что именно ты хочешь проверить.

Как просить ИИ написать тесты

Самый важный навык — правильно описать задачу. Чем конкретнее промпт, тем лучше результат.

Формула промпта

1. Контекст: что это за проект и где находится код.
2. Что тестировать: какую функцию или сценарий.
3. Ожидаемое поведение: что должно произойти при корректных и некорректных входных данных.
4. Граничные случаи: что должно случиться в крайних ситуациях.
5. Где сохранить: путь к файлу теста и какой фреймворк использовать.

Пример промпта

В проекте browser-snake есть файл game.js с функцией moveSnake(direction).
Напиши для неё юнит-тесты на Jest.

Что проверить:
1. При direction = 'UP' голова змейки перемещается вверх по сетке.
2. При direction = 'LEFT' голова перемещается влево.
3. Если новая позиция совпадает с яблоком, длина змейки увеличивается на 1.
4. Если новая позиция выходит за границы поля, функция возвращает 'GAME_OVER'.
5. Если новая позиция совпадает с телом змейки, функция возвращает 'GAME_OVER'.
6. Нельзя задать направление, противоположное текущему (например, LEFT, если текущее RIGHT).

Сохрани тесты в файл __tests__/game.moveSnake.test.js.

Ещё пример — для магазина

В проекте browser-snake есть файл shop.js с функциями buySkin(skinId) и selectSkin(skinId).
Напиши интеграционные тесты на Jest.

Что проверить:
1. Покупка скина уменьшает баланс coins на цену скина.
2. После покупки skinId попадает в массив ownedSkins.
3. Повторная покупка выбрасывает ошибку ALREADY_OWNED.
4. Покупка при недостатке монет выбрасывает ошибку NOT_ENOUGH_COINS.
5. selectSkin(skinId) устанавливает activeSkin, только если скин куплен.
6. Если activeSkin не выбран, используется скин по умолчанию 'default'.

Используй мок для localStorage, чтобы тесты не зависели от браузера.

Пример E2E-теста

Напиши E2E-тест на Playwright для игры browser-snake.

Сценарий:
1. Открыть index.html.
2. Нажать кнопку «Начать игру».
3. Нажать стрелку вправо, чтобы змейка пошла вправо.
4. Подождать один игровой тик.
5. Убедиться, что координата головы змейки изменилась.
6. Нажать стрелку влево и убедиться, что змейка не развернулась — direction остался RIGHT.

Сохрани в e2e/snake-movement.spec.js.

Правило хорошего тона

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

Чего не надо тестировать

Новички иногда увлекаются и пытаются протестировать всё. Это замедляет разработку и не даёт пропорциональной выгоды.

Не трать время на:

• Проверку внешнего вида пиксель в пиксель. Позиция кнопки может меняться по дизайну — это нормально.
• Тестирование сторонних библиотек. Если используешь готовый плеер звука, не проверяй, как он работает внутри.
• Слишком много E2E-тестов. Они запускаются медленно. Делай несколько критичных сценариев E2E, а детали проверяй юнит-тестами.
• Тесты ради тестов. Если сценарий очевиден и никогда не ломался, возможно, он не стоит усилий.

Заключение + чек-лист

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

Новичку не нужно становиться экспертом по тестированию. Достаточно понимать, что тестируем, зачем, и уметь чётко описать это ИИ. ИИ напишет код проверок, а ты — научишься читать их результаты.

Чек-лист «Хочу надежные тесты для Змейки»

• Я понимаю, какие сценарии в игре самые важные для игрока.
• У меня есть юнит-тесты на движение и столкновения змейки.
• Я проверяю сохранение рекорда в localStorage.
• Если есть магазин, у меня есть тесты на покупку, баланс и применение скина.
• У меня есть хотя бы один E2E-тест на запуск игры и базовое управление.
• Я запускаю тесты перед тем, как считать фичу готовой.
• Если тест падает, я сначала проверяю код игры, а не удаляю тест.
• Я не пытаюсь протестировать каждую строчку — только критичные пути.
• Я использую промпты с конкретным поведением, граничными случаями и указанием места сохранения.
• Я знаю, как запустить тесты одной командой в терминале.