/test

Простым языком

В проекте есть автоматические проверки — тесты. Они как чек-лист: «кнопка работает? форма сохраняется? ошибки показываются?». Напиши /test — Claude запустит все проверки и объяснит что сломалось и почему, если что-то не так.

Это не просто запустить тесты — Claude читает результат и говорит конкретно: «вот эта функция сломалась, вот почему, вот как починить».

Что делает

/test запускает тесты проекта, анализирует результаты и даёт конкретные рекомендации. Автоматически определяет тест-раннер по конфигам проекта, показывает coverage по файлам, разбирает падения с предложениями исправления. Это не просто npm test — это анализ.

Синтаксис

# Запуск всех тестов
/test

# Конкретный файл или директория
/test src/api/auth.test.ts
/test src/services/

# Только coverage (без запуска)
/test --coverage-only

Пошаговый процесс

1. Находит конфиги: jest.config.*, vitest.config.*, pytest.ini — определяет тест-раннер
2. Запускает тесты с coverage флагом
3. Анализирует результаты: прошедшие / упавшие / пропущенные
4. Для каждого упавшего теста: объясняет причину на понятном языке
5. Проверяет coverage: какие файлы ниже 80% порога
6. Даёт конкретные рекомендации: что написать, какие edge-cases добавить
7. Показывает сводку: X прошло, Y упало, покрытие Z%

Примеры использования

Анализ падения после рефакторинга

Переименовали функцию — тесты упали. /test покажет точно какие тесты и почему, не заставит читать километры jest-вывода.

# Пример вывода /test:
Тест-раннер: Jest 29.7
Запущено: 47 тестов в 12 файлах

ПРОШЛО: 44
УПАЛО:   3
  ✗ auth.test.ts:34 — validateToken не определена
    Причина: функция переименована в verifyToken (src/lib/jwt.ts:12)
    Исправление: заменить validateToken → verifyToken в тесте

  ✗ reactions.test.ts:67 — timeout 5000ms
    Причина: мок не настроен для нового параметра fingerprint
    Исправление: добавить fingerprint: 'test-hash' в фикстуру

Coverage: 76% (ниже порога 80%)
Файлы без покрытия: src/lib/telegram.ts (0%), src/utils/date.ts (45%)

Проверка перед деплоем

Перед пушем в прод — запускаете /test для уверенности. Если всё зелёное — продолжаете, если нет — Claude сразу указывает что чинить.

# Интеграция в workflow:
/test                  # запуск + анализ
  ↓ если 0 падений
/pre-commit-check      # финальные проверки
  ↓
git commit + git push

Автоматизация

В Quality Gate 2 тесты запускаются автоматически после написания кода. В /done — финальный прогон. В CI через GitHub Actions — при каждом пуше в main. Если тесты упали в CI — Auto-Fix Pipeline пытается исправить до 3 раз.

# GitHub Actions конфиг (автоматически генерирует /new-project):
- name: Тесты
  run: npm test -- --coverage --ci
  env:
    NODE_ENV: test
    DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}

Разница между /tdd и /test: /tdd ведёт через написание тестов, /test запускает и анализирует уже написанные.