На предмет чего тестировать REST API?

Question

[izac]

Добрый день , имеется REST API написанное на yii2 , было дано задание написать для каждого метода API тест , проблема в том что я не могу понять что считать эталонными данными для сравнения с ответом , так-как написал тест на вызов какого либо метода API и проверки что код ответа 200 , и тип ответа JSON , и сверки всех типов данных в JSON объекте , было сказано руководителем что мало , и нужно сверять с данными, но я думаю делать статические данные через фикстуры это не верно , так как их может быть довольно много (например в методе который получает все продукты , которых может быть много) , вытягивать из БД , тоже кажется не правильным подходом , так как в моделе может быть какая либо бизнес логика , и тогда её нужно переводить в код теста ?

Comments

[Moskus]

Как насчет того, чтобы спросить у руководителя, что он имеет в виду, а не ждать, что тут собрались телапаты и ясновидящие?

[izac]

Moskus, да завтра так и сделаю , просто прочитал пару статей , ответов на SO , и все пишут что тестируют код ответа + что это объект JSON. Может это просто не правильный подход , например каждую функцию безнес логики тестировать Unit тестами , а API тесты как в выше и описал ?

[Moskus]

izac, это зависит от того, что является предметом тестов и что считается частью API, а что - нет. Вы вот написали тест для составляющих, касающихся самого общего уровня: запрос-ответ и формат ответа. А ваш начальник, возможно, считает, что нужно тестировать еще содержимое ответа (логику). Это не ситуация, когда прав только кто-то один, но чтобы знать, что делать, нужно знать, какова цель. Тут вам никто мысли начальника не прочитает.

[izac]

Moskus, Полностью согласен , просто не могу понять где брать тестовые данные , если например я задам их статично , то при добавлении новых данный они будут != статичным , а если же я буду брать динамически и эту "логику" буду воспроизводить в тесте где , например , допущена ошибка тогда тест её покажет.

[Виталий]

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

Answer 1

[Никита]

Как проверить калькулятор?

1. Пишем на листочке 2+2=? 4.
   
2. Клацаем по калькулятору данные символы, получилось 4 - тест пройден, не 4 - не пройден.
   
3. Пишем на листочке 888*1234 = ? решаем в столбик или любым другим способом как умеем. 1095792
   
4. Клацаем по калькулятору данные символы, получилось 1095792 - тест пройден, не получилось 1095792 - не пройден.
   
5. И тд.
   

Вкраце: нужно где-то собственноручно записать требуемые данные и сверять с ними.

Answer 2

[Boris Köln]

я думаю делать статические данные через фикстуры это не верно , так как их может быть довольно много (например в методе который получает все продукты , которых может быть много) , вытягивать из БД , тоже кажется не правильным подходом

Это должны быть именно фикстуры www.yiiframework.com/doc-2.0/guide-test-fixtures.html
Если товаров много - генерируйте их в цикле. Делайте API-запрос к своему REST и сравнивайте ответ с ожидаемым.