Позитивные и негативные проверки данных

Негативный запрос тоже должен быть точным

Сначала создайте базовый валидный запрос и убедитесь, что его контекст корректен: адрес, токен, media type и исходные данные. Затем меняйте одно условие. Если одновременно удалить токен и испортить JSON, A1 даст 401; вы ничего не узнаете о парсере JSON. Порядок проверок важен для ожидаемой ошибки, а изолированные примеры помогают локализовать нарушение.

У тела есть несколько независимых уровней. Без Content-Type application/json стенд возвращает 415; с этим заголовком и обрезанным JSON —400; с синтаксически правильным JSON {"title":null} —422. Эти ответы относятся к разным основаниям. Не называйте любой ошибочный ввод «плохим JSON»: число 42 и null допустимы в JSON как значения, но не удовлетворяют схеме нашего поля title.

Отсутствие поля не равно null

Для description и priority контракт задаёт defaults только при отсутствии. {"title":"План"} создаёт description="" и priority=normal. Явное description:null нарушает строковый тип и должно дать 422; пустая description="" допустима. Title обязательный, поэтому отсутствие, null, число, пустая строка — разные отрицательные классы. Unknown authorId также запрещён; клиент не должен тихо управлять серверным авторством.

Для длины title используйте воспроизводимые точки 0,1,2,79,80,81 с одной кириллической буквой, затем отдельный случай 80 эмодзи😀. Ключевой оракул — кодовые точки Unicode. Для JSON-файла можно сформировать строку программно; не считайте число байт запроса длиной title. Description имеет собственную границу 500, а priority является перечислением. Случайный длинный текст не объясняет, какое именно условие вы проверили.

Отказ без побочного эффекта — часть контракта

Правильный 422 ещё не доказывает, что задача не была создана перед ошибкой. Снимите контролируемое состояние до запроса и сравните после: все ID и поля должны совпасть по A6. Проверка одного старого ID слишком узкая: новая лишняя запись может появиться рядом. В лаборатории snapshot специально доступен через отдельный ключ local-only, чтобы изучать этот инвариант на синтетических данных. В настоящей системе способ наблюдения выбирают в пределах разрешений.

Запишите expected status, error.code и неизменность отдельно. Когда тест падает, понятное имя показывает, нарушен ли ответ, форма ошибки или данные. Большой единственный assert «всё верно» затрудняет разбор. Одновременно не требуйте неописанный точный текст message: A6 обещает error.code, а не локализованную формулировку. Полезная строгость следует контракту; проверка случайных деталей реализации делает набор хрупким.

Три разных уровня отказа