Уровни проверки и контракт состояния
Разделяем функцию, доменный сценарий, HTTP-интеграцию и UI, проверяем права и отсутствие побочных эффектов.
- Подбирать уровень проверки под риск и наблюдаемое поведение.
- Проверять успешный переход и точный отказ без изменения состояния.
- Не выдавать объект со status за реальный сетевой запрос.
Уровень следует из границы
Тест validateTitle получает строку и возвращает boolean. Его граница — одна чистая функция. Тест createStore().publishTask соединяет политику доступа, переход состояния и хранилище в памяти. Он шире, но всё ещё не проверяет HTTP-маршрутизацию, десериализацию JSON, токены, реальные транзакции и браузер. Если позже появится HTTP-адаптер, понадобятся отдельные проверки фактического метода, заголовков, тела и сохранённого состояния.
Называйте уровень так, чтобы коллега понимал область доказательства. «Контракт доменного адаптера в памяти» точнее, чем «API полностью пройден». Похожая форма ответа не означает одинаковую интеграцию. Один важный бизнес-риск может проверяться на нескольких уровнях, но не требует механического дублирования каждого сочетания через UI. Быстрая проверка функции хорошо исследует границы, а немногочисленный сквозной сценарий подтверждает, что реальные компоненты действительно связаны.
Успех и отказ имеют разные доказательства
Для публикации t1 Анной ожидается 200, изменение только state на published и сохранение трёх исходных задач. Проверка одного status пропустит создание лишней копии или trim заголовка. Сравните полный snapshot с ожидаемой копией исходного массива, где изменено ровно одно поле одной записи. Возвращаемое тело тоже должно соответствовать обновлённой задаче.
Обычный участник Boris не вправе публиковать чужую t1: ожидается 403 и неизменный snapshot. Редактор Vera той же команды вправе её публиковать, хотя не читает чужой draft. Это необычное, но явное учебное правило A4/A5: нельзя вывести возможность чтения из возможности действия. Для чужой команды объект скрыт с 404, для отсутствия actor первым будет 401. Порядок проверок — часть этого контракта, а не универсальная рекомендация HTTP всем продуктам.
Отказ и сохранность состояния
const store = createStore();
const boris = {id:'boris',teamId:'red',role:'user'};
const before = store.snapshot();
assert.deepEqual(store.publishTask('t1',boris), {
status:403, body:{error:'FORBIDDEN'}
});
assert.deepEqual(store.snapshot(),before);Минимальный набор, который отличает правила
Начальное состояние включает чужой draft и пробельный title. Для t3 публикация Анной даёт 422, хотя само создание такой строки допустимо. Повторная публикация t1 после успешной первой даёт 409. Вызов отсутствующего id без actor даёт 401 раньше проверки существования. Участник из другой команды получает 404 и не меняет данные. Эти проверки различают состояния, роли, команды и валидность, а не просто перебирают случайные числа.
Для каждого негативного сценария создавайте новый store и снимок до действия. Когда проверка падает на первом assertion, последующий snapshot может не выполниться; поэтому описание результата не должно утверждать, что все побочные эффекты уже исследованы. В buggy-версии пропущено правило разрешения публикации: тест обычного коллеги получит 200 вместо 403 и остановится. Причина фиксируется по фактическому ответу, а отдельный запуск или дополнительное наблюдение может показать мутацию.
Зафиксируйте это разделение в названиях suites. В проектном плане распределите риски: функция отвечает за длину; адаптер — за переход и доменные права; настоящий HTTP-тест — за передачу личности и кодирование; UI-тест — за доступное управление и отображение. Пока два последних уровня не запускались, оставьте их статус «не выполнено». Это не уменьшает ценность готовых проверок: точная граница позволяет использовать результат без ложной уверенности.
Источники и проверка фактов
Node.js · Assert strict modeТочные структурные сравнения.Playwright · API testingПример отдельного сетевого уровня, отсутствующего в нашем in-memory наборе.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1