Проверка в базе после вызова API: результат или реализация

Тимур · бэкенд, #qa-antrakt

Ладно, 58 мест. Убедили, база правдивее API. Предлагаю правило: каждый API-тест после вызова лезет в базу и сверяет строки во всех таблицах, которые трогал. Тогда ни один баг не спрячется.

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

Половина таких проверок полезна, половина навредит. Через месяц Тимур переименует колонку, и покраснеют сто тестов без единого бага. Разбери, где граница. Тесты Глеба на сервис заказов как раз написаны по этому правилу, начни с них.

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

Такси и маршрут

Ты вызвал такси до вокзала. Что значит «поездка удалась»? Ты на вокзале, вовремя, и списали обещанную сумму. Это результат.

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

Тест API, который после вызова читает таблицы, может быть и тем, и другим. Если он смотрит, приехал ли пассажир, это проверка результата. Если сверяет повороты, это проверка реализации, и она покраснеет в день, когда Тимур поедет переулками.