test-master - Тесты, покрытие и разбор сбоев проверок

Когда звать

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

Какие проверки объединяет Test Master

Test Master помогает агенту составлять тестовый план, писать проверки и разбирать результаты. В прочитанном SKILL.md стоит версия 1.1.1. В области применения есть unit, интеграционные и E2E-тесты, нагрузочные проверки и проверки безопасности.

В отличие от скилла одного фреймворка, он задаёт общие правила тестирования. Автор перечисляет Jest, Vitest и pytest, а для нагрузки - k6 и Artillery. Выбор конкретного инструмента должен зависеть от проекта и цели проверки, а не от желания добавить ещё один тестовый пакет.

Порядок работы с тестами

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

В коротком примере важны конкретные ожидания: проверка сравнивает вычисленное значение с ожидаемым, а неверный ввод должен вызвать определённую ошибку. Просто проверить, что результат не пустой, недостаточно. Автор требует проверять наблюдаемое поведение вместо внутренних вызовов реализации.

В unit-тестах внешние API и базы нужно подменять. Это требование не означает, что интеграционные проверки всегда обходятся без базы: область теста определяется отдельно. Рабочие данные инструкция запрещает использовать; для воспроизводимых случаев предлагает fixtures или factories.

Что делать с падающими проверками

После неуспешного запуска агент должен различить ошибку ожидания, сбой окружения и нестабильность. Для flaky tests автор направляет искать зависимость от порядка и неправильное ожидание асинхронных операций. Повторять запуск до случайного зелёного результата запрещено.

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

Справочники разделены по unit, интеграционным, сквозным, нагрузочным и защитным проверкам. Есть материалы по отчётам, методологии, автоматизации, TDD и антишаблонам тестирования. Основной файл прямо указывает, что часть тем адаптирована из проекта obra/superpowers по MIT.

Пример первого задания

Можно попросить: «Для функции импорта составьте таблицу случаев: корректный файл, пустой ввод, повреждённая запись и отказ зависимости. Добавьте изолированные тесты и покажите результат каждого запуска». Такой запрос задаёт поведение до выбора деталей реализации.

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

В паспорт внесены закреплённые SKILL.md и LICENSE. Мы не устанавливали коллекцию и не запускали созданные скиллом тесты; Codex не проверен. Разбор первопричины уже обнаруженного сбоя можно продолжить с Debugging Wizard.