Нужно ли проверять, что сервис возвращает все возможные варианты ответов

Что проверяют

Понимаете ли вы, что множество ответов сервиса конечно и описано контрактом, в отличие от множества входных данных. И проверяете ли вы не только код ответа, но и тело, заголовки и побочные эффекты.

Как отвечать

Да, проверять надо все варианты, но список берётся из спецификации, а не из фантазии. По описанию метода выписываются успешные ответы и ошибочные: неверные данные, нет авторизации, нет прав, ресурс не найден, конфликт состояния, превышен лимит запросов, отказ зависимости, таймаут.

По каждому ответу проверяется:

• тело по схеме: обязательные поля, типы, пустой массив против отсутствия поля, допустим ли null;
• единый формат ошибки с машиночитаемым кодом, без трассировки стека и текста запроса к базе наружу;
• заголовки: тип содержимого, правила кэширования, Retry-After рядом с ответом про лимит;
• повторный вызов: идемпотентен ли метод, не создаётся ли второй объект.

Сокращать набор помогают классы эквивалентности: из каждого класса неверных данных берётся один представитель, а не все возможные значения. Отказ зависимости воспроизводится заглушкой, ждать настоящего сбоя бессмысленно. Расхождение схемы дешевле ловить контрактными тестами, а не сквозными сценариями.

Где спотыкаются

Понимают «все варианты ответов» как перебор всех входных данных и объявляют задачу невыполнимой. Входов бесконечно много, ответов конечное число, и именно они перечислены в контракте.

Смотрят только на код ответа. Ответ 200 с пустым телом, с null вместо списка или с текстом ошибки внутри успешной структуры такую проверку проходит спокойно.

Не проверяют, что осталось в системе после ошибки. Списаны ли деньги, ушло ли письмо, не завис ли объект в промежуточном статусе. Ответ про внутреннюю ошибку при уже созданной записи это худший дефект из всего списка, и находится он только проверкой состояния после вызова.