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

Сделал изменение в коде — и что-то сломалось в другом месте. Тесты — это как охранники: они автоматически проверяют что всё работает после каждого изменения. Этот скилл заставляет Claude писать эти проверки сразу.

Ты добавил новую функцию — Claude сам придумает и запустит проверки. Если что-то сломается в будущем, тесты сразу покажут где именно.

Что делает

Скилл testing — полное тестирование проекта: unit, integration, E2E. Claude выбирает правильный уровень тестов для каждой задачи по пирамиде тестирования, пишет реальные тесты (не болванки), запускает и фиксит фейлы.

Тесты пишутся сразу в той же сессии, не откладываются "на потом". Это не опционально.

Когда использовать

Написал новый модуль с бизнес-логикой
Добавил API-эндпоинт (POST/PUT/DELETE)
Реализовал критичный флоу: авторизация, платежи, регистрация
Рефакторинг — нужно убедиться что ничего не сломалось
CI/CD падает — нужно локально воспроизвести и пофиксить

Пирамида тестов

Claude выбирает уровень по правилам:

Unit — функция с логикой? Есть if/else, расчёты, трансформация → пишем unit
Integration — API-эндпоинт или работа с БД → пишем integration
E2E — критичный пользовательский флоу (авторизация, оплата) → пишем E2E
Smoke — один раз при инициализации проекта, проверяем что всё стартует

Промпты для Claude

Напиши тесты для функции calculateDiscount в src/lib/pricing.ts.
Покрой все ветки: скидка 0%, 10%, 20%, невалидный ввод.

Напиши integration-тесты для POST /api/questions.
Тестируй: создание с валидными данными, 401 без авторизации,
400 при невалидном теле запроса, 429 при rate limit.

Пример теста

// tests/unit/pricing.test.ts
import { описатьСкидку } from '@/lib/pricing'

describe('описатьСкидку', () => {
  it('возвращает 0 для нового пользователя', () => {
    expect(описатьСкидку({ заказов: 0 })).toBe(0)
  })

  it('даёт 10% после 5 заказов', () => {
    expect(описатьСкидку({ заказов: 5 })).toBe(0.1)
  })

  it('бросает ошибку при отрицательных заказах', () => {
    expect(() => описатьСкидку({ заказов: -1 })).toThrow(
      'Количество заказов не может быть отрицательным'
    )
  })
})

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

Запуск тестов в CI при каждом push:

# .github/workflows/test.yml
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test -- --coverage
      - run: npx jest --coverageThreshold='{"global":{"lines":80}}'

Частые вопросы

Сколько моков — это нормально?

Правило: если в unit-тесте больше 3 моков — скорее всего нужен integration-тест. Слишком много моков = тест тестирует моки, а не логику.

Нужно ли 100% покрытие?

Нет. Целевой показатель — 80% для бизнес-логики. Геттеры, конфиги, маппинги можно не тестировать. Фокус на тестах, которые реально ловят баги.

testing

Описание