Как организовать запуск тестов в проекте?

Организация запуска тестов — это не только выбор библиотеки, но и договорённость о том, как команда и CI будут вызывать проверки. Хорошо настроенный запуск делает тесты предсказуемыми: одна команда запускает всё, другая — только быстрые unit-тесты, третья — e2e в изолированном окружении.

Базовые принципы

• Единая точка входа: скрипт в package.json, Makefile или task runner.
• Разделение по уровням: unit, integration, e2e — отдельные команды.
• Конфигурация в репозитории: jest.config.js, pytest.ini, .mocharc и т.п.
• Изоляция окружения: тестовые БД, моки внешних сервисов, переменные окружения.
• Автоматизация в CI: запуск на push, PR и по расписанию.

Пример для Node.js с Jest

// package.json
{
  "scripts": {
    "test": "jest",
    "test:unit": "jest --testPathPattern=unit",
    "test:e2e": "jest --config jest.e2e.config.js",
    "test:ci": "jest --ci --coverage --runInBand"
  }
}

// jest.config.js
module.exports = {
  testEnvironment: 'node',
  collectCoverageFrom: ['src/**/*.js'],
  setupFilesAfterEnv: ['./test/setup.js']
};

Пример для Python с PyTest

# pytest.ini
[pytest]
testpaths = tests
addopts = -ra -q --cov=app

# Makefile
test:
	pytest

test-unit:
	pytest tests/unit

test-integration:
	pytest tests/integration

Запуск в CI

В CI обычно выполняют установку зависимостей, подготовку сервисов (например, через docker-compose) и запуск тестов. Пример шага для GitHub Actions:

- name: Install
  run: npm ci
- name: Test
  run: npm run test:ci
  env:
    DATABASE_URL: postgres://user:pass@localhost:5432/test

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