В чём смысл писать функциональные тесты на Java, если есть postman и другие инструменты?

Question

[AnotherAnkor]

Есть Postman и SoapUI, которые часто используются для тестирования.
В каждом можно собрать коллекции. Каждый может быть интегрирован с CI. Из каждого можно собирать красивые отчёты.
Объясните мне, зачем нужно переписывать тесты на жабе или чём там ещё любят переписывать, если куда проще содержать автотесты в формате коллекции? Ведь тоже можно использовать переменные и все прочие плюшки. Просто зачем?

Answer 1

[Dmitry Roo]

Смысл появляется, если тесты становятся чуть сложнее, чем проверка результатов http запроса.

Comments

[AnotherAnkor]

Это делается и в коллекциях. Так что пока это не ответ.

[Dmitry Roo]

AnotherAnkor, допустим вы тестируете crud, и вам нужно протестировать создание записи в БД.
Запрос вы сделали и получили ответ "ОК".
Вы сможете в постмане сходить в БД и проверить создана запись или нет?

[Алексей Уколов]

Или что в очередь было положено задание на отправку письма какого-нибудь.

[AnotherAnkor]

Dmitry Roo, если crud, то есть и прочие методы, кроме создания и кода в ответе "201" (и будь прокляты те, кто считает, что "200").
Следовательно - да, я смогу.

[AnotherAnkor]

Алексей Уколов, на самом деле, в одном случае я бы использовал groovy или жабу, ибо soapui позволяет использовать произвольный код, а в другом nodejs. Кейс странный в примере, но ок - можно.

[Алексей Уколов]

Ничего странного в кейсе нет, он встречается примерно в 100% более-менее сложных проектов.

Идём дальше: мы хотим протестировать поиск по продуктам. Продукт не может существовать без раздела и цены для данного типа пользователя. Мы либо в тесте под капотом засидим базу нужными данными, либо пойдём через Postman создавать по цепочке через API все эти сущности (по дороге борясь с валидацией, которая, может включать в себя, например, обязательность картинки, загруженной через multipart-форму). Мне вот как-то кажется, что первый способ проще.

Следовательно - да, я смогу.

У записи могут быть служебные поля, которые не отдаются в ответе API, но заполнение которых важно проверить.

В общем - использовать только Postman для тестирования хоть сколько-то сложного проекта не получится. И тогда встаёт вопрос: а зачем вообще тесты разбивать на два инструмента?

[AnotherAnkor]

Алексей Уколов, мне почему-то кажется, что твой пример исчезающе редок и в целом некорректен. Но может это реальный проект, на котором просто не было опытного тестировщика. Обычно подход, что сейчас описал ты, свойственен джунам и трейни. Но это не для обидеть, а мой опыт.

[VolgaVolga]

AnotherAnkor, кажется вы ищете подтверждения своему убеждению, а не ответа.

на жабе или чём там ещё любят переписывать

Ну да, так и есть.

Подобных вопросов задают много, вроде: "Зачем уметь программировать, если есть плагины на все случаи жизни?".

Answer 2

[Влад Григорьев]

AnotherAnkor, Есть много историй с кафка или redis - где нам надо ходить и вариантов нет - и тут постман пролетает.
Есть также всякие ui и скриншотные тесты, которые тоже надо писать и на постмане не сделать .
А есть достаточно более сложные тесты где нам надо не только отправлять запросы, но слушать websoket, sse и не факт что только под одним пользователем.
Плюс есть всякие штуки на создание и прочее, которые тоже простыми не бывают. И нам приходится использовать разные паттерны разработки.
Да и много чего еще чего есть. Что если и можно сделать через постман - то это дорого и больно сложно.

Но это не значит что постман плохой инструмент - это лиш значит, что он хорошо себя показывает в конкретных кейсах, на конкретных проектах.

Если вы тестите простые веб-сервисы с простой логикой, то да отличный инструмент для автоматизации. И возможно что-то другое избыточно

Comments

[AnotherAnkor]

Сорян, что не указал rest api и оставил варианты для интерпретаций.

Answer 3

[Василий Банников]

Смысл - если уже есть компетенции на жаве, а в постмане нет.

Comments

[AnotherAnkor]

Но при этом те же тестеры присылают свои коллекции и порой даже с переменными среды. Я всё ещё не понимаю.