Навыки test-driven-development

📦

test-driven-development

Name: test-driven-development
Author: ZhanlinCui

Безопасно

Применять тестово-ориентированную разработку

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

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

Поддерживает: Claude Codex Code(CC)

🥉 74 Бронза

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

Загрузить в Claude

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

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

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

Использование «test-driven-development». Мне нужно добавить функцию для валидации email-адресов

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

Начнём с TDD. Сначала я напишу падающий тест:

```typescript
test('rejects invalid email', () => {
expect(validateEmail('invalid')).toBe(false);
});
```

Теперь я запущу этот тест, чтобы подтвердить его падение...

Использование «test-driven-development». Функция login должна обрабатывать неправильные пароли

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

Следуя TDD, сначала тест:

```typescript
test('rejects wrong password', async () => {
const result = await login('user@test.com', 'wrongpass');
expect(result.success).toBe(false);
expect(result.error).toBe('Invalid credentials');
});
```

Запускаю тест для верификации падения...

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

Безопасно

v1 • 2/24/2026

This is a legitimate Test-Driven Development educational skill. The static analyzer detected 73 potential issues, but after semantic evaluation, all findings are FALSE POSITIVES. The 'external_commands' detections are markdown code block delimiters (backticks) in documentation, not actual shell execution. The 'weak cryptographic algorithm' and 'network reconnaissance' detections are similarly false positives triggered by keywords in educational context. No executable malicious code exists in this skill.

Просканировано файлов

672

Проанализировано строк

находки

Всего аудитов

Проблемы среднего риска (1)

Markdown Code Block Delimiters Flagged as Shell Execution

The static scanner detected 'Ruby/shell backtick execution' patterns in markdown files. These are FALSE POSITIVES - the backticks are markdown code fence delimiters (```typescript, ```bash) used for syntax highlighting in documentation, not runtime command execution. The skill is educational content about TDD methodology with no actual shell commands being executed.

Проверено: claude

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

Архитектура

100

Сопровождаемость

Контент

Сообщество

100

Безопасность

Соответствие спецификации

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

Реализация новой функциональности

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

Рабочий процесс исправления ошибок

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

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

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

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

Начать TDD для новой функциональности

Мне нужно реализовать [опишите функциональность]. Следуя TDD, сначала напишите падающий тест, который определяет ожидаемое поведение. Пока не пишите код реализации.

Верификация Red-фазы

Запустите только что написанный тест и подтвердите, что он падает по правильной причине (отсутствует функциональность, а не из-за опечаток). Покажите мне точное сообщение об ошибке.

Green-фаза — минимальная реализация

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

TDD для исправления ошибки

Есть ошибка, при которой [опишите ошибку]. Сначала напишите тест, который воспроизводит эту ошибку и падает. Затем я её исправлю.

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

Пишите по одному тесту за раз — фокусируйтесь на одном поведении
Называйте тесты по поведению, которое они верифицируют, а не по тому, что тестируется
Всегда дожидайтесь падения теста перед написанием реализации
Держите реализацию минимальной — только для прохождения текущего теста

Избегать

Написание кода реализации до тестов (затем «адаптация» тестов)
Сохранение падающего кода реализации как «справочного» при написании тестов
Тесты, которые проходят сразу — они ничего не доказывают
Тестирование поведения моков вместо поведения реальных компонентов

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

Что такое тестово-ориентированная разработка?

TDD — это методология, при которой вы сначала пишете падающий тест, затем пишете минимальный код для его прохождения, затем делаете рефакторинг. Цикл: Red (падение), Green (прохождение), Refactor.

Почему писать тесты до кода?

Тесты, написанные после кода, проходят сразу, ничего не доказывая. Написание тестов сначала заставляет вас определить желаемое поведение и доказывает, что тест действительно ловит ошибки.

Что делать, если тест сложно написать?

Сложность написания тестов часто указывает на то, что дизайн слишком сложен. Упростите интерфейс или используйте внедрение зависимостей, чтобы сделать код тестируемым.

Можно ли пропустить TDD для простого кода?

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

Что делать, если я уже написал реализацию?

Удалите его. Начните заново с TDD. Сохранение существующего кода и добавление тестов после defeats the purpose и даёт ложную уверенность.

Замедляет ли TDD разработку?

Нет. TDD находит ошибки до коммита, предотвращает регрессии и позволяет безопасный рефакторинг. Отладка постфактум медленнее, чем TDD.