development

Тестирование

@dev-test

1 000 000 токенов в подарок

бесплатно при регистрации — для знакомства с агентом

0 установокобновлено сегодняПубличный

О навыке

Проверяет, что код действительно работает: пишет и запускает тесты, сверяет результат с критерием приёмки из ТЗ, отлаживает по алгоритму «воспроизведи → локализуй → минимизируй → исправь → защити». Применяйте для «проверь / протестируй», «не работает — почини», «покрой тестами», «найди баг», «убедись, что работает». Не подходит для написания основной реализации (dev-build), сбора требований (dev-spec) или ведения проекта (dev-project).

Кому подходит навык Тестирование

Разработчикам и фрилансерам — доказать, что код работает, а не «кажется working».
Командам MVP — покрыть ключевую логику тестами без перегруза корпоративной пирамидой.
Тем, кто чинит баги — отлаживать по алгоритму, а не менять наугад.
Заказчикам и продакт-менеджерам — сверить результат с критерием приёмки из ТЗ.

Что можно сделать

Проверить, что код работает — тест или ручной прогон с реальным вводом как свидетельство.
Покрыть ключевую логику тестами — юнит-тесты на вычисления, парсинг, валидацию плюс один сквозной тест наключевой путь.
Найти и починить баг — по алгоритму «воспроизведи → локализуй → минимизируй → исправь корень → защити».
Сверить с критерием приёмки — для каждого пункта из SPEC.md ответить, каким тестом он доказан.

Связанные навыки: Разработка, ТЗ и архитектура, Ведение проекта.

Как это работает: свидетельство, а не мнение

Любое утверждение «работает» опирается на факт: тест зелёный, команда выполнена с таким-то выводом, ввод X дал вывод Y. Для бага используется лёгкий red-green — сначала тест, воспроизводящий его (красный), потом фикс, который делает его зелёным. Так баг закрыт доказуемо и не вернётся. Критерий приёмки из SPEC.md — это и есть спецификация проверки: если там написано «вставил ссылку → получил график за 30 дней», тест именно это и прогоняет.

Полезные детали

Алгоритм отладки из 5 шагов нельзя перепрыгивать: сначала воспроизвести надёжно, потом локализовать.
Корень, а не симптом: заплатка порождает следующий баг рядом.
Кросс-платформенный запуск: Python — pytest -q, Node — node --test (встроено, без зависимостей).
Регрессия: после фикса прогоняются все смежные тесты.

Готовы доказать, что работает? Запустите навык Тестирование или начните с ИИ-разработчика.

Частые вопросы

Что считается доказательством, что код работает?

Зелёный тест или ручной прогон с реальным вводом. «Я запустил — работает» сильнее, чем «должно работать»: тест зелёный, команда выполнена с таким-то выводом, ввод X дал вывод Y. Без проверяемого свидетельства это догадка.

Сколько тестов нужно для MVP?

Один-два слоя, без корпоративной пирамиды: юнит-тесты на ключевую логику (вычисления, парсинг, валидация) — обязательно, и один сквозной тест наключевой путь пользователя — желательно. E2E/UI-автоматизация для MVP обычно избыточна.

Как чинятся баги?

По алгоритму из пяти шагов, который нельзя перепрыгивать: воспроизвести надёжно → локализовать (сузить область) → минимизировать тест-кейс → исправить корень, а не симптом → защитить тестом, чтобы баг не вернулся.

Можно ли закомментировать падающий тест?

Нет. Это борьба с симптомом, а не с причиной — баг вернётся в другом месте. Падающий тест удалять нельзя; сначала воспроизведение и локализация, потом фикс корня.

На чём запускать тесты кросс-платформенно?

Python — pytest -q или python -m unittest; Node — node --test (встроено, без зависимостей) или npm test. Команды даются на языке проекта, без предположения о bash.

Это платно?

Навыком можно пользоваться в рамках тарифа AgentHere — оплата идёт за токены при работе модели. Точные лимиты смотрите на странице тарифов.

Инструкции

Тестирование и отладка

Доказать, что код работает — не «кажется working», а проверяемое свидетельство. Две задачи навыка: проверить (тесты + сверка с ТЗ) и починить (отладка).

Когда активирован

«Проверь / протестируй / убедись, что работает».
«Не работает / падает / выдаёт не то — почини».
«Покрой тестами», «напиши тесты», «найди баг».
После реализации среза (dev-build) — как выходной контроль.

Не активируй для написания основной реализации (dev-build) или сбора требований (dev-spec).

Главный принцип: свидетельство, а не мнение

«Я запустил — работает» ≫ «должно работать». Тест или ручной прогон с реальным вводом — это свидетельство. Любое утверждение «работает» должно опираться на: тест зелёный, команда выполнена с таким-то выводом, ввод X дал вывод Y. Без этого — это догадка.

Критерий приёмки из SPEC.md — это спецификация проверки. Если в SPEC.md написано «пользователь вставляет ссылку → получает график за 30 дней», то тест именно это и прогоняет: реальная ссылка → есть график → 30 точек.

Часть 1. Проверка

Пирамида тестов (не перегружай)

Для MVP достаточно одного-двух слоёв — не строй корпоративную пирамиду:

Юнит-тесты на ключевую логику (вычисления, парсинг, валидация) — обязательно.
Один сквозной тест на核心ный путь пользователя (критерий приёмки) — желательно.
E2E/UI-автоматизация — отложить, для MVP обычно избыточна; ручной прогон дешевле.

Лёгкий red-green

Сначала тест падает (red) на нужном поведении, потом код делает его зелёным.
Это защищает от теста, который ничего не проверяет.
Для бага: сначала тест, воспроизводящий баг (red) → фикс → тест зелёный. Так баг закрыт доказуемо и не вернётся.

Сверка с критерием приёмки

Пройдись по SPEC.md и для каждого пункта приёмки ответь: «каким тестом/прогоном это доказано?». Если пункт не покрыт — это либо дыра, либо его не нужно было в MVP (тогда убрать из SPEC). Не оставляй непроверенные требования.

Как запускать (кросс-платформа)

Python: pytest -q (есть pytest) или простой python -m unittest.
Node: node --test (встроено, без зависимостей) или npm test.
Без фреймворка: минимальный скрипт test.js/test.py, который печатает OK/FAIL и выходит с кодом 0/1. Этого достаточно для MVP.
Не предполагай bash — команды запуска давай на языке проекта (см. dev-build §кросс-платформа).

Часть 2. Отладка (когда не работает)

Алгоритм из пяти шагов — не перепрыгивай:

Воспроизведи надёжно. Нельзя починить то, что не воспроизводишь. Зафиксируй точные шаги, ввод, окружение. Если плавающий баг — найди условия, при которых он повторяется стабильно.
Локализуй. Сузь область: убери всё лишнее, оставь минимальный ввод, на котором баг есть. Бинарный поиск по коду/коммитам (отключай половину — баг остался?).
Минимизируй тест-кейс до самого короткого, на котором баг воспроизводится. Короткий кейс = быстрая проверка фикса.
Исправь корень, а не симптом. Понимай почему баг возник, не лепи заплатку, гасящую проявление. Заплатка порождает следующий баг рядом.
Защити: добавь тест на этот кейс (чтобы не вернулся) и проверь, не сломал ли фикс что-то ещё (регрессия — прогони остальные тесты).

Анти-паттерны отладки

«Поменяю наугад, вдруг пройдёт» — это не отладка, это лотерея. Сначала локализуй.
«Заккомментирую падающий кусок» — симптом, а не корень. Тест потом всё равно упадёт.
«У меня работает» — а у пользователя нет. Проверяй в условиях пользователя (ОС, данные).

Границы (✅ / ⚠️ / 🚫)

✅ Всегда: тест на核心ную логику; тест-кейс для каждого бага; прогонять после фикса всю смежную область.
⚠️ Спросить: внедрять тяжёлый тест-фреймворк/E2E-инфраструктуру в MVP; менять схему ради тестируемости.
🚫 Никогда: не удалять падающий тест; не помечать баг «починил» без зелёного теста на кейс; не глушить вывод ошибок, чтобы «выглядело чисто».

Отговорки и почему они не работают

Отговорка	Почему мимо
«Это и так очевидно работает»	Очевидно ≠ доказано. Один прогон с реальным вводом — и готово.
«Тесты замедлят MVP»	Один баг в проде стоит дороже десяти тестов. Минимум — на核心ную логику.
«Поменяю, потом проверю»	Сначала воспроизведение и локализация. Иначе чинишь не то.
«Заккомментирую, чтобы зелено»	Симптом. Баг вернётся в другом месте.

Выходные критерии

Критерий приёмки из SPEC.md покрыт тестом или воспроизводимым прогоном.
Каждый найденный баг закрыт тестом-кейсом (зелёным после фикса).
Регрессия проверена — смежные тесты зелёные.
Если что-то не покрыто или не чинится — честно сказано пользователю, что осталось и какой риск (без «вроде готово»).

Комментарии (0)

Войдите, чтобы оставить комментарий

Загрузка комментариев...