npm test и CI: как не публиковать сломанную игру

Ты дописал очередную фичу в «Змейке»: добавил счёт, звук при поедании яблока и новый экран «Игра окончена». Запускаешь у себя в браузере — всё работает. Заливаешь на GitHub, радуешься, кидаешь ссылку другу. А он отвечает: «У меня змейка вообще не двигается, а счёт показывает NaN». Такое случается, когда в проекте нет проверки качества. Разберём, как команда npm test и сервис GitHub Actions помогают ловить такие косяки до того, как игра попадёт к пользователям.

Почему тесты — это не «для программистов», а для тебя

Автотесты — это маленькие роботы, которые проверяют, что твоё приложение работает правильно. Они не заменяют тебя, но берут на себя рутину: «если змейка съела яблоко, счёт должен увеличиться на 1», «если змейка врезалась в стену, игра заканчивается», «если нажать пробел, пауза включается».

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

Тесты — это страховка. Они не гарантируют идеальный код, но резко снижают шанс опубликовать сломанную игру.

Что на самом деле делает npm test

Когда в терминале ты вводишь команду npm test, Node.js читает файл package.json проекта и ищет там секцию scripts с ключом test. Примерно так:

{
  "scripts": {
    "test": "node --test"
  }
}

После этого Node запускает указанную программу. В нашем примере это встроенный в Node тестовый раннер, который находит файлы с тестами, выполняет их и выводит результат в терминал.

npm — это менеджер пакетов Node.js. Он умеет не только скачивать библиотеки, но и запускать команды проекта. npm test — это просто сокращение для «выполни то, что написано в скрипте test».

Тестовый файл для «Змейки» может выглядеть так:

const { test } = require('node:test');
const assert = require('node:assert');
const { increaseScore } = require('./game.js');

test('счёт растёт после поедания яблока', () => {
  const score = increaseScore(5);
  assert.strictEqual(score, 6);
});

Запускаешь npm test — раннер находит этот файл, выполняет функцию increaseScore(5) и проверяет, что результат равен 6. Если всё верно, в терминале появляется зелёная галочка. Если нет — красная ошибка с описанием, что сломалось.

Что такое CI и при чём тут GitHub Actions

CI расшифровывается как Continuous Integration — непрерывная интеграция. Проще говоря, это автоматическая проверка кода каждый раз, когда ты что-то добавляешь в репозиторий.

Представь, что у тебя есть помощник. Каждый раз, когда ты отправляешь изменения на GitHub, он берёт чистый компьютер, скачивает твой код, устанавливает зависимости, запускает npm test и сообщает результат. Если тесты прошли — код считается здоровым. Если нет — ты сразу узнаёшь, что что-то сломалось.

GitHub Actions — это встроенный в GitHub сервис для такой автоматизации. Он бесплатен для публичных репозиториев и для небольших приватных проектов в пределах лимитов. Подробности о тарифах лучше смотреть на официальном сайте GitHub.

Самый распространённый сценарий для новичка: запускать тесты перед публикацией сайта на GitHub Pages. Так страница не обновится, если в коде есть ошибка.

Как GitHub Actions гоняет тесты перед публикацией на Pages

Вся настройка живёт в файле .github/workflows/test-and-deploy.yml внутри проекта. Это обычный текстовый файл, который описывает, что делать GitHub при каждом изменении.

Типичный сценарий состоит из двух этапов:

1. Проверка. GitHub создаёт виртуальную машину, клонирует твой репозиторий, устанавливает Node.js, запускает npm install и затем npm test.
2. Публикация. Если проверка прошла успешно, GitHub собирает сайт и выкладывает его на GitHub Pages.

Пример простого workflow:

name: Test and Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npm install
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 22
      - run: npm install
      - run: npm run build
      - name: Deploy to GitHub Pages
        uses: actions/deploy-pages@v5

Ключевая строчка — needs: test. Она говорит: «Развёртывание начнётся только после успешного прохождения задания test». Если тесты упали, публикация не произойдёт.

Что происходит, если тест не прошёл

Скажем, ты случайно изменил функцию движения змейки, и теперь она уползает за пределы поля. У тебя есть тест «змейка не выходит за границу холста». npm test запускает его, видит нарушение и возвращает ошибку.

В терминале это выглядит примерно так:

✖ змейка не выходит за границу холста (2.341ms)
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
  + actual - expected
  + 12
  - 10

В GitHub Actions эта же ошибка появится во вкладке Actions твоего репозитория. Задание test будет помечено красным крестиком, а задание deploy не запустится. GitHub Pages останется со старой, рабочей версией игры.

Это и есть главная польза: ты узнаёшь о проблеме до того, как пользователи её заметят. Исправляешь код, коммитишь снова — и процесс повторяется с чистого листа.

Как применить это к «Змейке» — минимальный пример

Не нужно сразу покрывать всё тестами. Начни с самых важных сценариев, которые легко сломать:

• счёт увеличивается при поедании яблока;
• игра заканчивается при столкновении со стеной или собой;
• рекорд сохраняется в localStorage;
• кнопка паузы работает корректно.

Для простой браузерной игры часто достаточно встроенного в Node тестового раннера. Если логика разбита на отдельные функции, тестировать их легко.

Шаги для подключения:

1. Убедись, что в package.json есть скрипт test.
2. Создай папку test/ и добавь туда файлы с проверками.
3. Запусти npm test локально — убедись, что всё проходит.
4. Создай файл .github/workflows/test-and-deploy.yml, который сначала тестирует, потом публикует.
5. Запушь изменения на GitHub и проверь вкладку Actions.

Если тестов ещё нет, но ты уже публикуешь сайт, не паникуй. Добавь хотя бы один-два самых важных теста и настрой workflow постепенно. Главное — начать.

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

npm test и GitHub Actions — это способ автоматически проверять качество кода до публикации. Вместо того чтобы надеяться, что «вроде работает», ты получаешь чёткий сигнал: зелёная галочка — можно выкладывать, красный крест — нужно чинить.

Для «Змейки» это особенно важно, потому что игра быстро обрастает функциями: скины, звуки, магазин, PWA, таблица рекордов. Каждое нововведение может сломать старое. Автотесты и CI помогают держать проект в порядке без постоянной ручной проверки.

Чек-лист «Тесты и CI подключены»

• В package.json есть скрипт test.
• Есть хотя бы несколько тестов на ключевую логику игры.
• npm test проходит успешно локально.
• В репозитории создан файл .github/workflows/test-and-deploy.yml.
• Workflow сначала запускает тесты, а потом публикует сайт.
• После пуша во вкладке Actions видно, что задание test прошло.
• Если тест падает, публикация на GitHub Pages не происходит.
• Перед добавлением новой фичи сначала пишешь или обновляешь тесты.
• Используешь официальную документацию GitHub Actions и npm при настройке.

Источники

1. Документация npm — команда npm test: docs.npmjs.com/cli/commands/npm-test
2. Документация GitHub Actions: docs.github.com/en/actions