# Тестирование Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b Синхронизировано: 2026-11-09T11:15:07.649Z Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b ## Оглавление - [Тестирование по риску](#testing-risk) - [Регрессионные тесты](#testing-regression) - [Интеграционные тесты](#testing-integration) - [End-to-end тесты](#testing-critical-paths) - [Статус проверок](#testing-honest-checks) - [Детерминизм тестов](#testing-determinism) # Тестирование по риску ## Коротко Проверяйте наблюдаемое поведение, которое действительно может сломаться. ## Плохо ```text Тест проверяет, что константа равна самой себе. ``` ## Хорошо ```text Тест проверяет отказ в доступе к чужому заказу. ``` ## Почему Большое число тестов не гарантирует полезного покрытия. ## Когда применять Для простой правки текста достаточно просмотра. Для авторизации, денег и данных нужны отрицательные и интеграционные сценарии. ## Как проверить - Какую реальную ошибку обнаружит каждый новый тест? ## Человек Оценивает последствия ошибки и выбирает достаточную глубину проверки. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Какую реальную ошибку обнаружит каждый новый тест? ## Источники - [Google Testing Blog: Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/risk.md) --- # Регрессионные тесты ## Коротко Для исправления бага полезно сначала воспроизвести неправильное поведение. ## Плохо ```text Тест написан после исправления и всегда проходил. ``` ## Хорошо ```text На старой версии тест падает по нужной причине. На исправленной — проходит. ``` ## Почему Так проверка подтверждает причину исправления, а не случайную деталь реализации. ## Когда применять Если автоматизация нецелесообразна, сохраните воспроизводимый ручной сценарий и ограничение. ## Как проверить - Тест действительно отличает старое поведение от нового? ## Человек Подтверждает исходную ошибку и ожидаемое исправленное поведение. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Тест действительно отличает старое поведение от нового? ## Источники - [Writing your first Django app, part 5](https://docs.djangoproject.com/en/5.2/intro/tutorial05/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/regression.md) --- # Интеграционные тесты ## Коротко Изолированные тесты не заменяют проверки SQL, миграций и форматов взаимодействия. ## Плохо ```text Mock всегда возвращает успех; реальная миграция не запускается. ``` ## Хорошо ```text Тестовая БД → миграции → запрос → проверка результата. ``` ## Почему Ошибка схемы или прав БД может не проявиться в mock. ## Когда применять Используйте отдельную тестовую среду и ограниченные данные. Рабочая база не должна служить полигоном. ## Как проверить - Проверены реальные права роли и ограничения схемы? ## Человек Определяет границы, где ошибка взаимодействия наиболее опасна. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Проверены реальные права роли и ограничения схемы? ## Источники - [Google Testing Blog: Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html) - [PostgreSQL: Documentation: 18: 5.5. Constraints](https://www.postgresql.org/docs/18/ddl-constraints.html) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/integration.md) --- # End-to-end тесты ## Коротко Небольшой набор сквозных тестов должен покрывать основные пользовательские действия. ## Плохо ```text Есть unit-тесты, но кнопка сохранения не связана с API. ``` ## Хорошо ```text Вход → создание → повторное открытие. Отдельно — отказ доступа и ошибка сети. ``` ## Почему Правильные компоненты могут быть неправильно соединены. ## Когда применять Не заменяйте все быстрые тесты медленными e2e. Выбирайте сценарии с наибольшей ценой ошибки. ## Как проверить - Можно ли пройти основной путь на узком экране? ## Человек Выбирает критические пользовательские сценарии. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Можно ли пройти основной путь на узком экране? ## Источники - [Google Testing Blog: Just Say No to More End-to-End Tests](https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/critical-paths.md) --- # Статус проверок ## Коротко Публикуйте точный объём проверки, версию и ограничения. ## Плохо ```text CI зелёный, хотя скрипт проверяет только наличие папок. ``` ## Хорошо ```text Проверена структура. Runtime-тесты пока отсутствуют. ``` ## Почему Статус должен объяснять, что именно подтверждено. ## Когда применять Это инженерное правило справочника, а не требование протокола. Первоисточник описывает подход или механизм; конкретный процесс выбирается проектом. Проверки контента, линтер, сборка и тест поведения доказывают разные вещи. ## Как проверить - Откройте команды проверки и сопоставьте их с заявленным результатом. ## Человек Принимает результат с учётом реально выполненных и пропущенных проверок. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Откройте команды проверки и сопоставьте их с заявленным результатом. ## Источники - [Status checks - GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/honest-checks.md) --- # Детерминизм тестов ## Коротко Управляйте временем, случайностью и внешними зависимостями в тестах. ## Плохо ```text Тест ждёт sleep(10) и зависит от рабочего API. ``` ## Хорошо ```text Управляемые часы и фиксированные данные. Ожидание конкретного состояния. ``` ## Почему Случайные падения делают команду нечувствительной к настоящим ошибкам. ## Когда применять Карантин нестабильного теста должен иметь владельца и срок исправления. ## Как проверить - Можно ли повторить сбой с теми же входными данными? ## Человек Определяет значимые внешние условия и допустимую нестабильность. ## Агент Подбирает проверку под риск, запускает её и сообщает результат вместе с оставшимися ограничениями. Контроль результата: - Можно ли повторить сбой с теми же входными данными? ## Источники - [Best Practices](https://playwright.dev/docs/best-practices) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/testing/tdd-strict/rules/determinism.md)