Архитектура API-тестов, часть 2: модели, билдеры, фабрики, декораторы и свои проверки

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

Посмотрела твой PR со слоями. Транспорт, клиенты, шаги, конфиг: всё на месте, импорты чистые. Но открой test_orders.py. В каждом тесте словарь заказа на пять полей, и в половине из них поля разные. Пользователя три теста создают тремя способами. А вчерашний ночной прогон упал с assert 500000 == 535000, и я двадцать минут выясняла, какой это был заказ и какой запрос. Слои ты построил, теперь наведи порядок внутри них.

В прошлом уроке ты разложил код Глеба по слоям: транспорт знает про HTTP, клиенты ресурсов знают пути, шаги знают сценарии, тесты знают только шаги. Слои отвечают на вопрос «кто что знает». Но внутри каждого слоя остаётся вопрос «как это написать, чтобы не повторяться и чтобы падение было понятным». На него отвечают паттерны.

Паттерн это название, а не цель

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

Сегодня пять таких решений. Каждое закрывает одну жалобу Веры:

Жалоба	Решение
словарь заказа на пять полей в каждом тесте	модель запроса и билдер
пользователя создают тремя способами	фабрика
в отчёте нет запроса, который упал	декоратор транспорта
assert 500000 == 535000 без контекста	свои проверки с понятным сообщением
OrderApi(UserApi) у Глеба, логика в тестах	разбор антипаттернов