Схема ответа: модели pydantic и zod, JSON Schema из OpenAPI

Ника · фронтенд, #qa-antrakt

После истории с «null ₽» я завела на фронте zod-схему на каждый ответ API. Вчера в 14:05 афиша на проде показала белый экран: Тимур поменял сериализатор, и seats_left стал приходить строкой "50". Моя схема упала сразу, а ваши тесты API зелёные до сих пор. Почему мой фронт знает про контракт больше, чем ваши тесты?

Вера Ланская · лид QA, #qa-antrakt

Потому что у Ники контракт записан один раз и проверяется на каждом ответе, а у нас разбросан по тестам и проверяется там, где кто-то вспомнил. Сделай так же.

В уроке 50 схема была одной строкой из пяти в таблице проверок. Ты проверял её руками: isinstance(order["id"], int) здесь, регулярное выражение для времени там. Так можно проверить пару полей в паре тестов. Так нельзя держать контракт целой ручки, а тем более двадцати ручек. Сегодня вынесем схему в отдельный объект, сделаем её строгой и научимся проверять ею каждый ответ одной строкой.

Калибр вместо линейки

На заводе, который точит болты, контролёр не меряет каждый болт штангенциркулем. У него есть калибр: железная пластина с двумя прорезями. В одну болт обязан пролезть, в другую не должен. Приложил, и через секунду ясно, годен болт или нет. Калибр делают один раз по чертежу, а прикладывают к тысячам болтов.

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