Валидация респонсов веб-сервисов в автотестах (Java, SQL)

Ну вообще-то девушка хотела узнать про подходы к проверке респонса от веб-сервиса и как хранить тестовые данные для этого…А вы сразу про что лучше iOS или Android :smile: Никто даже не уточнил какой веб-сервис, а вдруг там бородатое SOAP вместо REST?)

Бородатый - это CORBA services… или еще что похуже.

По поводу вопроса топик-стартера, то мы у себя не храним респонсы. Делаем валидацию по схеме, проверяем конкретные поля и значения в них сравнивая с ожидаемвми. Ожидаемые же значения либо указаны в тесте (data source), либо вычисляются непосредственно в тесте, либо берутся из базы. Например, если делаем зачисление на счет. Сумму берем из файла с параметрами, текущий баланс узнаем до проведения операции и сохраняем в hashmap, а ожидаемый баланс вычисляем сами в тесте как сумма + предыдущий баланс. Как-то так.

Если же проверяем запрос продуктов у клиента, то там коллекция ожидаемых значений из базы и сравнивается с коллекцией продуктов из xml. Точнее там более сложная структура - хешмэпа хешмэп. Причем есть ключ который ищет соответствующий блок и соавнивает нужные между собой и все это в цикле + проверка общего числа, что блоков столько же. Это немного муторно и возможно не всем подойдет, поэтому не рекламирую данный подход.

Спасибо за ответы всем, кто откликнулся :slight_smile:
В целом данные у нас не меняются, есть снапшот БД, который накатывается пару раз в неделю. Но другие тесты могут менять данные, при этом забывать/фейлить tearDown() и т.д.
Заранее готовить данные - отличный вариант, но у нас не получится, довольно сложная структура БД (+ юзера заливаются через приложение файлами).
Сейчас ребята придумали хранить json файлы для каждого кейса и сравнивать с респонсами, файлов будут сотни. Сомнительный вариант имхо.
Я считаю оптимальным делать выборку из БД. Боюсь только погрязнуть в поддержании скриптов, т.к. структура БД сложная и меняется периодически.