Знакомая история: метод должен отклонять
quantity: 0. Передали ноль, получили 422, тест прошёл, галочка поставлена ✅.А потом выясняется: сервис прекрасно создаёт заказ с нулевым количеством. Просто в тесте вместе с quantity подставлялся случайный productId, которого нет в базе. 422 прилетел из-за отсутствующего товара, а до проверки количества дело вообще не дошло 📉.
Попалась статья на Хабре про эту проблему, и оказывается она системная, а не разовая случайность 📊. Мы меняем несколько полей, ждём любой 4xx, и считаем, что валидация работает. А запрос мог остановить кто угодно: API Gateway, парсер JSON, просроченный токен, вообще другое бизнес-правило 🚧.
Разбирается там несколько практических моментов:
- почему невалидный запрос лучше собирать из валидного, а не с потолка 🧱
- почему в одном тесте стоит нарушать только одно правило 🎯
- почему 422 не равно 409, и "любой 4xx" на самом деле ничего не доказывает 🤷♂️
- почему одного статус-кода мало, и нужен стабильный код ошибки в теле ответа 📝
- и главное: как проверить, что после ошибки система действительно не поменяла состояние: заказ не создался, остаток не изменился, событие не улетело в очередь 🔒
Отдельно интересно про автогенерацию тестов из OpenAPI: инструмент прекрасно готовит невалидные данные, но не знает бизнес-контекст 🤖. Он не в курсе, должен ли конкретный запрос занять ключ идемпотентности или создать запись в outbox.
Почитать целиком: [статья]
А какие у вас были случаи, когда зелёный негативный тест на самом деле не проверял то, что должен был? Делитесь в комментариях 👇