Навыки test-driven-development
📦

test-driven-development

Безопасно

Освойте практику тест-драйвен разработки

Также доступно от: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra

Написание тестов после кода не доказывает, что они действительно что-то тестируют. Эта практика требует цикла Red-Green-Refactor, где каждый тест должен падать перед реализацией, гарантируя, что тесты проверяют реальное поведение.

Поддерживает: Claude Codex Code(CC)
📊 70 Адекватно
1

Скачать ZIP навыка

2

Загрузить в Claude

Перейдите в Settings → Capabilities → Skills → Upload skill

3

Включите и начните использовать

Протестировать

Использование «test-driven-development». Реализовать функцию, которая повторяет неудачные операции 3 раза

Ожидаемый результат:

  • Шаг 1 (RED): Написать тест 'повторяет неудачные операции 3 раза'
  • Шаг 2: Запустить тест — верифицировать падение, потому что логика повторных попыток не существует
  • Шаг 3 (GREEN): Реализовать минимальный цикл повторных попыток
  • Шаг 4: Запустить тест — верифицировать прохождение
  • Шаг 5 (REFACTOR): Вынести логику повторных попыток при необходимости

Использование «test-driven-development». Баг: Пустой email принимается в форме

Ожидаемый результат:

  • RED: test('отклоняет пустой email') — ожидать ошибку 'Email required'
  • Верификация: Тест падает — форма сейчас принимает пустой email
  • GREEN: Добавить проверку валидации для пустого email
  • Верификация: Тест проходит, нет регрессий
  • Результат: Баг исправлен с тестом, предотвращающим регрессию

Аудит безопасности

Безопасно
v1 • 2/25/2026

This skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.

2
Просканировано файлов
674
Проанализировано строк
0
находки
1
Всего аудитов
Проблем безопасности не найдено
Проверено: claude

Оценка качества

38
Архитектура
100
Сопровождаемость
87
Контент
23
Сообщество
100
Безопасность
91
Соответствие спецификации

Что вы можете построить

Разработка новых функций

Используйте TDD при реализации новых функций, чтобы гарантировать наличие соответствующих тестов для каждой функции, доказывающих корректное поведение перед коммитом

Исправление багов с предотвращением регрессии

Сначала напишите падающий тест, воспроизводящий баг, затем реализуйте исправление, гарантируя, что баг не сможет вернуться

Рефакторинг с уверенностью

Используйте существующий набор тестов для верификации неизменности поведения во время реструктуризации или оптимизации кода

Попробуйте эти промпты

Базовый цикл TDD 
Мне нужно реализовать [feature]. Помогите мне сначала написать падающий тест, описывающий ожидаемое поведение, затем проведите меня через Red-Green-Refactor.
Исправление бага с TDD 
Баг: [describe bug]. Помогите мне написать тест, воспроизводящий этот баг (должен падать), затем реализовать минимальное исправление для его прохождения.
Ревью качества теста 
Проверьте мой тест для [function]. Он тестирует реальное поведение или поведение моков? Ясно ли название теста? Тестирует ли он одну вещь?
Проверка анти-паттернов TDD 
Я собираюсь [action]. Проверьте, нарушает ли это принципы TDD. Тестирую ли я поведение моков? Добавляю ли код только для тестов? Мокаю без понимания?

Лучшие практики

  • Всегда наблюдайте падение теста перед реализацией — это доказывает, что тест действительно что-то тестирует
  • Пишите минимальный код для прохождения теста — никаких лишних функций, никакого овер-инжиниринга
  • Удаляйте код реализации, если пропустили цикл TDD, и начинайте заново с тестов

Избегать

  • Написание кода реализации до существования теста
  • Тестирование поведения моков вместо поведения реального кода
  • Добавление методов только для тестов в продакшн-классы

Часто задаваемые вопросы

Что если я уже написал код реализации?
Удалите его. Время уже потрачено. Перепишите с использованием TDD, начиная с падающего теста. Сохранение непроверенного кода — технический долг.
Могу ли я написать тесты после реализации?
Нет. Тесты, написанные после, сразу проходят, ничего не доказывая. Вы тестируете то, что построили, а не то, что требуется. TDD требует тестов сначала.
Что если код слишком простой для тестирования?
Простой код тоже ломается. 30-секундный тест предотвращает будущие баги. Если стоит отправить в продакшн, стоит протестировать.
Как работать с существующим кодом без тестов?
Добавьте тесты для существующего поведения перед внесением изменений. Сначала протестируйте текущее поведение, затем используйте TDD для новых функций.
Что если настройка теста слишком сложная?
Сложные тесты указывают на сложный дизайн. Упростите интерфейс, вынесите хелперы или используйте dependency injection.
Когда можно пропустить TDD?
Только для прототипов на выброс, сгенерированного кода или файлов конфигурации. Для продакшн-кода всегда используйте TDD, если ваш человеческий партнёр не одобрит исключение.

Сведения для разработчиков

Автор

sickn33

Лицензия

MIT

Репозиторий

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-development

Ссылка

main

Структура файлов

📄 SKILL.md

📄 testing-anti-patterns.md