Tdd

Skill Avalon-27reg/smyslokod-starter/.claude/skills/tdd

Стек-агностичный шаблон смысло-кодинга для Claude Code: бизнес-контекст в business/, планы фич, ретроспективы, правила и готовые промпты. Стек выбираешь на старте.

Install

npx -y skills add Avalon-27reg/smyslokod-starter --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this when the user asks for a new pure function, business-logic module, calculator, validator, or anything where input→output is well-defined and easily testable. Drives Red-Green-Refactor instead of writing untested code. Skip for UI components, throwaway scripts, and config changes.

SKILL.md

4.9 KB, as published. Nobody here has run it

Skill: tdd

Test-Driven Development по циклу Red → Green → Refactor. Не догма, а инструмент: применяй где это реально ускоряет, а не где «положено».

Когда применять

Любое из:

Новая чистая функция (вход → выход) — расчёт, валидатор, парсер, конвертер.
Бизнес-логика с понятными правилами (скидки, цены, лимиты, доступы).
Багфикс воспроизводимого бага (см. также скилл diagnose).
Часть кода, которую планируем рефакторить — тесты страхуют.

Когда НЕ применять

UI-компонент, где визуал важнее логики (используй ручную проверку + Playwright позже).
Прототип / разовый скрипт, который выкинут через час.
Интеграция с внешним API без чёткого контракта (сначала разведка, потом тесты).
Простая правка конфига или копи.

Цикл (Red → Green → Refactor)

Шаг 1 — Red (тест падает)

Назови ожидание словами: «при входе X должно получиться Y».
Напиши один тест, который проверяет это ожидание. Не пять сразу.
Запусти тест → должен упасть. Если не упал — тест неверный (что-то проверяет случайно).
Если тест падает с «module not found» / «is not a function» — это нормально, это «red».

Шаг 2 — Green (минимальная реализация)

Напиши минимальный код, чтобы тест прошёл.
Допускается «прибить гвоздями» (захардкодить ответ), если это самое простое.
Цель этого шага не «красивый код», а «тест зелёный».
Запусти все тесты — все зелёные.

Шаг 3 — Refactor (улучшаем без потери зелёного)

Убрать дублирование, дать осмысленные имена, разбить на функции.
После каждого изменения — прогнать тесты.
Если тесты красные — откатываемся, переделываем меньшими шагами.

Шаг 4 — Следующий случай

Добавь следующий тест: edge case, граница, пустой вход, ошибка.
Снова Red → Green → Refactor.

Какие тесты писать в первую очередь

Порядок приоритета:

Happy path — типичный вход → ожидаемый выход.
Граничные значения — 0, 1, пустая строка, последний день месяца.
Ошибки — неверный тип, отрицательное число, null.
Регрессии — для каждого пойманного бага — тест, который его ловит.

Что вернуть пользователю

После цикла — короткий отчёт:

Тестов написано: N штук, какие случаи покрывают.
Файлы: tests/<...>.test.ts и src/<...>.ts через path:line.
Команда запуска: как пользователь сам прогонит локально.
Что НЕ покрыто: честно перечисли непокрытые сценарии (не маскируй).

Антипаттерны

Тест, который проходит даже если код сломан (плохое утверждение).
Один тест на 50 ассертов — при падении непонятно что сломалось.
Тестировать имплементацию вместо поведения (привязка к моку приведёт к ложному зелёному в проде).
«Тесты потом, сначала код» — это не TDD, это «надежда что напишу позже».
Моки на свою же базу данных в смысло-критичных местах (см. правило о integration tests в .claude/rules).