📦

tdd

Безопасно

Написание тестов с использованием разработки через тестирование

Также доступно от: Benny9193

Написание тестов после кода создает хрупкие системы, которые ломаются при рефакторинге. Этот навык проведет вас через разработку через тестирование, где тесты определяют поведение до реализации, что приводит к более чистому коду и надежному рефакторингу.

Поддерживает: Claude Codex Code(CC)
🥉 74 Бронза
1

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

2

Загрузить в Claude

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

3

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

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

Использование «tdd». Help me build a feature to add items to a shopping cart

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

I'll guide you through TDD for this feature. First question: what should happen when a user adds an item? Should we support quantity? What behavior should be verifiable?

Использование «tdd». Write tests for user authentication

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

For auth testing, focus on public interfaces: login, logout, session handling. I recommend integration-style tests over mocking internal auth logic. What external services does your auth use?

Использование «tdd». I have tests that break whenever I refactor

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

Your tests are likely coupled to implementation details. Good tests verify behavior through public interfaces. Let's identify which tests break and what they're testing.

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

Безопасно
v1 • 4/19/2026

All 48 static findings are false positives. The skill contains educational TDD documentation with code examples. External command flags were triggered by ASCII workflow diagrams (RED→GREEN patterns). Cryptographic algorithm flags were triggered by testing patterns like jest.mock() and StripeClient(). No malicious code or prompt injection detected.

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

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

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

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

Создание новых функций с помощью TDD

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

Исправление ошибок с помощью падающих тестов

При сообщении об ошибке этот навык помогает написать падающий тест, воспроизводящий ошибку, а затем направляет исправление кода для прохождения теста.

Улучшение унаследованного кода через рефакторинг

Перед рефакторингом унаследованного кода этот навык помогает написать интеграционные тесты, фиксирующие текущее поведение, обеспечивая сохранность функциональности при рефакторинге.

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

Новая функция с TDD
Мне нужно добавить [функция] в [модуль]. Помогите использовать TDD для сборки. Начните с вопроса о том, какое поведение тестировать в первую очередь.
Исправление ошибки с помощью TDD
Есть ошибка, где [описание]. Помогите написать падающий тест, который это воспроизводит, затем исправьте.
Улучшение тестового покрытия
Я хочу улучшить тесты для [модуль]. Просмотрите мои текущие тесты и предложите улучшения следуя принципам TDD.
Рефакторинг с уверенностью
Я хочу провести рефакторинг [модуль]. Помогите написать тесты, которые сначала фиксируют текущее поведение, затем направьте мой рефакторинг.

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

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

Избегать

  • Написание всех тестов сначала, затем всей реализации (горизонтальное разрезание)
  • Мокирование внутренних участников вместо тестирования через открытые интерфейсы
  • Написание тестов, проверяющих детали реализации, а не поведение

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

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

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

Автор

mattpocock

Лицензия

MIT

Ссылка

main

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