Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Запуск теста с разными параметрами (когда их много)

execution
java
testng
Теги: #<Tag:0x00007f7b60385170> #<Tag:0x00007f7b60385030> #<Tag:0x00007f7b60384ec8>

(Kosmos) #1

Добрый день.

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

Как в этом случае быть?

Пока нашел 2 способа решения:

  1. Использовать запуск в цикле. Не очень нравится, как-то не красиво
  2. Использовать аннотацию @Parametrize. Но он вроде запускает проверку параллельными данными.

Кто что может посоветовать/скинуть ссылку почитать?


(Остап Олексин) #2

Если используете TestNG то смотрите в сторону data providers - http://www.tutorialspoint.com/testng/testng_parameterized_test.htm


(Vasiliy Rakshin) #3

В каком виде эти данные о 100 пользователях? где они хранятся?


(Ivan Klymchuk) #4

Если данные не будут использоваться в дальнейшем, можно генерить их в рантайме по маске соответствия требованиям.
Если есть заранее подготовленные данные, можно хранить:

  1. Файлы (csv, xml,…) - самый распространенный;
  2. База данных - это избыточно для подобного кейса, но иногда необходимо;
  3. Получать с ресурсов, сервисов, third-party components.

Последние два варианта включают интеграцию с компонентами, потому чаще всего выбирают первый вариант.


(rise) #5

можно брать данные из csv файлов. если используете Serenity BDD то посмотрите в сторону SerenityParameterizedRunner
http://thucydides.info/docs/serenity-staging/#_data_driven_tests


(Kosmos) #6

в целом не важно как брать. Думаю, как можно проще и эффективнее (для данной задачи). Данные заранее подготовлены (пара: логин / пароль, могут быть разные данные). Смотрю в сторону CSV/PlainText формата хранения данных. Или где-то в файле .java в виде массива будут перечислены эти данные.


(Sewa Makhinya) #7

Я бы использовал параметризацию однозначно везде (кромее тех редких случаев, когда точно знаешь, что нужно крутить цикл).

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

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

Судя по синтаксису, речь идёт о Java. Тогда у нас два варианта xUnit: JUnit или TestNG. Оба хороши, JUnit чуть стандартнее и поэтому менее гибок (параметризует классы, а не методы). Лично я привык к JUnit и использую его по причинам совместимости + историческим.

Не в порядке рекламы, если хочется прокачатсья в теме - можно пройти тренинг http://software-testing.ru/shop/index.php?q=%2Fshop%2Fhome&page=shop.product_details&flypage=flypage.tpl&product_id=153&category_id=12&vmcchk=1&option=com_virtuemart&Itemid=1


(Farof Well) #8

Без всякой рекламы и головной боли берешь testNG и пишешь простой дата провайдер, он реализован не в пример проще чем в jUnit. Цикл использовать не надо. Почитать если то - Varun Menon TestNG Beginner Guide