Итоговый проект: надёжный набор публикации
Передаём автономный тестовый пакет, доказательства чувствительности и план недостающих интеграционных проверок.
- Собрать тестовый пакет из правил, fixtures и проверяемых результатов.
- Доказать обнаружение конкретных дефектов без подмены ожиданий.
- Отделить выполненные проверки от плана реальной HTTP/UI-интеграции.
Задача проекта
Вы принимаете в поддержку AUTO-CORE-1 и должны передать коллеге понятный набор автоматизированных проверок публикации. В поставке есть исправленный модуль и специально ошибочная версия. Цель — не максимальное число тестов, а проверяемая связь между правилами, данными, действием и результатом. Новый участник должен открыть папку, прочитать договор, выполнить одну основную команду и понять любой отказ без личного объяснения автора.
Составьте матрицу A1–A6 и перечислите, какие конкретные сценарии относятся к каждому правилу. Укажите известные пробелы. Например, граничные проверки title не покрывают автоматически все границы description; модель actor не проверяет криптографическую сессию; store в памяти не доказывает транзакционность базы. В итоговом пакете эти ограничения должны быть видны рядом с результатом, а не спрятаны в конце большого отчёта.
Что должно запускаться
Основной набор состоит из contract.test.mjs и diagnostics.test.mjs; рядом лежат orbitdesk.mjs и orbitdesk.buggy.mjs. Launcher run-buggy.mjs задаёт ошибочную реализацию только для отдельного диагностического запуска. Добавьте report.md с точной версией Node, командами, кодами завершения и фактическим выводом. Основная команда не требует npm-пакетов и не должна обращаться к внешнему стенду. Распакуйте файлы в новую папку, чтобы проверить полноту относительных imports.
Для неизменённого эталона основной результат 20 PASS / 0 FAIL / exit 0. Buggy-прогон:17 tests,13 PASS/4 FAIL/exit 1. Три причины — ошибка Unicode-длины, утечка чужого draft и пропущенное разрешение публикации. Четвёртый отказ повторно замечает утечку на предпосылке редакторского сценария. Самостоятельный отчёт должен содержать ваш вывод: копирование эталонных цифр без запуска оставляет статус «не выполнено».
Критерии качества теста
Каждый изменяющий сценарий владеет новым store. До отказа снимается независимый snapshot; после отказа ожидается точное равенство. Успех меняет ровно state нужной задачи и сохраняет число записей. Асинхронные действия завершаются внутри теста через await, а промежуточное состояние проверяется управляемым барьером. Название теста сообщает роль и правило, assertion — конкретную разницу. Случайные таймеры и глобальная изменяемая фикстура не должны быть частью решения.
Проверьте чувствительность, запуская тот же набор на buggy без правок expected. Для каждого обнаруженного дефекта сохраните минимальный вход и первую разницу. Не исправляйте баг удалением негативного сценария и не называйте одну мутационную проверку доказательством полноты. Полезный review-вопрос: какое неправильное поведение могло бы пройти этот набор? Ответ превращается в следующий приоритет тест-дизайна, а не в абстрактный процент качества.
План настоящих интеграций
Отдельно опишите будущий HTTP-сценарий: реальная сессия разрешённого стенда, POST или другой согласованный метод, передача actor только сервером, точная схема ответа и подтверждение сохранённого состояния. Это план, пока нет исполняемого адаптера и фактического запуска. Для UI используйте самостоятельный DOM-пример как упражнение с локаторами, но не соединяйте его результат с backend-моделью словом «сквозной».
Сдача проекта включает самопроверку по рубрике: независимые оракулы, воспроизводимость, изоляция, чувствительность к трём дефектам и честные статусы. Внешней экспертной проверки сайт не проводит. Если вы добавили новый тест, пересчитайте фактические total/pass/fail и обновите матрицу, сохранив исторические эталонные числа отдельно. Такая дисциплина делает набор поддерживаемым: следующий автор понимает не только как запустить, но и зачем существует каждое ожидание.
Источники и проверка фактов
Node.js · Running testsВоспроизводимая команда основного runner.Playwright · Best practicesНаблюдаемое поведение, изоляция и поддержка UI-тестов.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1