Проверка ответов API целиком |
04.03.2020 01:00 |
Автор: Энджи Джонс (Angie Jones) Большинство людей тестируют API спустя рукава. В своем воркшопе "Азбука API" я прошу людей вручную протестировать API. Получая ответ, они, как правило, бросают на него взгляд и, возможно, тщательно проверяют некоторые ключевые поля. То же верно и для автотестов – обычно проверяются только ключевые поля. Возьмем вот такой GET-запрос: http://api.zippopotam.us/us/20500 Он возвращает такой ответ: HTTP/1.1 200 OK Получая такой ответ, многие юнит-тесты убедятся, что код ответа 200, и тело не пустое. Функциональные тесты могут пойти дальше и проверить некоторые ключевые поля тела ответа. Большая часть людей не будет проектировать тесты, проверяющие КАЖДЫЙ кусочек ответа, потому что это очень времязатратно, и с шансами неверная информация в некоторых полях несет не такие уж большие риски. Я считаю, что вы не знаете, как пользователь может воспользоваться вашим API, и поэтому не можете утверждать, какое из этих полей наиболее важно. Из-за этого я искала способ проверить ответ целиком, используя только одну проверку. Я была близка к этому, десериализируя ответ API в POJO и сравнивая результат с ожидаемым объектом. Но даже при этом подходе мне нужно было кодировать POJO, и создавать ожидаемый объект в моем коде. Все равно времязатратно. К счастью, Марк Уинтерингэм сделал воркшоп по Approval Tests и показал, как проверить тело ответа целиком! Я пришла домой, попробовала сделать это самостоятельно, и мне это нравится! После первого прогона вашего теста Approval Tests сохранит ваш ожидаемый результат в файл. Затем для каждого последующего прогона он сравнит новый результат с сохраненным. Если результат отличается, тест падает, и дифф-программа вроде DiffMerge может показать вам разницу между файлами. Видео: https://video.twimg.com/tweet_video/DZ4gjREXkAEeQqI.mp4 ЗависимостиЯ создала pom-файл при помощи Approval Tests, TestNG (как прогонщика тестов), и Rest-Assured (для API). Отметьте, что Approval Tests может работать с любым прогонщиком тестов и любым API-инструментом, и поддерживает несколько языков разработки. <dependencies> Тестирование тела ответаВ этом тесте я хочу проверить тело ответа целиком. Я могу сделать это, вызывая Approvals.verify и передавая тело. Это проверяет тело, однако код статуса все еще может быть неверным. Поэтому я добавляю еще один вызов к методу Rest-Assured statusCode, чтобы проверить и статус тоже. @Test При первом выполнении тест упадет, потому что файл approved еще не сохранен.
Я беру результат, убеждаюсь, что он верен, и сохраняю его в файл approved. При повторном прогоне Approval Test сравнивает файл received, содержащий новую информацию, с файлом approved. Если они совпадают, тест пройден. Тестирование ответа целикомПроверки тела ответа вместе с кодом статуса может быть достаточно, но не повредит пойти дальше и проверить ответ целиком, включая заголовки. Тут я находила баги и ранее – например, заголовки с пагинацией. Я создала новый тест для проверки ответа целиком. Так как ответ включает код статуса, мне не нужна отдельная проверка для него. @Test Динамические данныеИспользуя эту технику, вы быстро столкнетесь с тем, что большая часть ответов динамична. Для вызовов POST ответ может включать заново сгенерированный ID. Заголовки могут включать дату или информацию о cookie, которая каждый раз разная. К счастью, я вспомнила, что Марк научил нас небольшому фокусу, чтобы справиться с этим. Так как мы работаем со строками, мы можем просто использовать replaceAll и регулярное выражение для поиска строк, которые динамичны – а затем замаскировать эти строки. В моем ответе три динамичных заголовка, поэтому я замаскировала их так: @Test Скачать кодЯ почистила код и разместила его на GitHub для вашего удобства. |