Выбор нужных тестов из нескольких (Java+Selenium+Junit).

java
junit
selenium
Теги: #<Tag:0x00007fedbc22e640> #<Tag:0x00007fedbc22e500> #<Tag:0x00007fedbc22e3c0>

#1

Помогите пожалуйста организовать механизм выбора нужных тестов. В классе описаны несколько тестов и в зависимости от входящих параметров, запускать нужно определенные из них, не прогонять все. Каким образом можно это организовать?

Используется Java+Selenium+Junit.


(Alexander) #2

Не помню как в junit точно, но кажется там есть параметр @Category.

Грубо говоря, вы помечаете тесты/сьюты категориями, а потом при запуске тестов раннером указываете какие категории хотите заранить. Принцип кажется такой.


(Михаил Братухин) #3

Да, категории норм тема. Я, кстати, почему-то сначала подумал, что они только на классе работают, а тут оказывается они и для методов должны работать, судя по документации.


(Mr Ds Low) #4
  1. Выключение ненужных тестов, включение нужных?
  2. Группировка и запуск группы.

(Баранов Иван) #5

А как Вы их сейчас запускаете?


#6

прочитала, наверное в моем случае не подойдет. Мне нужен какой-то анализатор, чтобы в динамическом режиме запускать нужные тесты в зависимости от входящего параметра. В дженкинсе будет запускаться джоба с параметрами и в зависимости от того, что надо проверить(один из параметров), нужно запускать определенные тесты из класса.


#7

Это все надо делать динамически, возможно такое?


(Михаил Братухин) #8

Что за параметр? Как много их вариаций может быть? У меня сделано с категориями и с динамической структурой тестов причем еще и с дата-провайдером внутри (правда, пришлось с этим повозиться). Делаете TestSuite какие вам нужны и в качестве параметра запускаете тесты по имени класса = имени TestSuite.
Команда мавена, выглядит примерно так:
mvn clean test -Dtest=${TestSuiteClassName}
Просто на все методы нужно будет раскидывать довольно много аннотаций, а также потом это дело поддерживать в актуальном состоянии.
Еще я у себя использовал Assume класс, который прерывает выполнение теста, если его поставить в самом начале, или вообще в before метод, т.е. тест будет skip’нут, но все же посчитан и отражен в прогоне, как пропущенный. Я такое делал для случая, если дата-провайдер не имеет данных для теста (сделали класс и забыли ему дать данные :slight_smile:) Если не пугают скипнутые тесты в отчетах, то можно тупо выставить условие какое-то и применять Assume или его аналоги.
http://junit.org/junit4/javadoc/4.12/org/junit/Assume.html
Тут дело в том, что структура тестов в Junit 4.x.x версий довольно статична и список запускаемых сценариев строится еще до всяких методов типа BeforeClasses, поэтому там не так много способов внести “динамику” в этот процесс. Но из вашего описания пока, что не очень понятно вообще о какой динамике идет речь. Чем вам не подходят заранее созданные наборы тестов (TestSuite), которые вы по своему усмотрению запускаете? Jenkins тоже не сильно динамичная штука. Один раз в мавен/градл передаст параметр на запуск тестов и дальше ждет их окончания. Никакой динамики пока я в этом кейсе не наблюдаю. Просто разные аргументы на вход в приложение.

P.S. Фишки 5-го Junit’а пока детально не изучал и у себя на проектах не применял, возможно, что там появилось еще что-то более удобное. Вот тут у них, что-то про динамичные тесты есть в 5-й версии: http://junit.org/junit5/docs/current/user-guide/#writing-tests-dynamic-tests, вообще для 5-й у них довольно неплохая документация сделана.

Есть еще более “дерзкий” вариант - сделать параметризированный тест, который внутри себя получает список методов из какого-нибудь DataProvider’а, который готовит списки для запуска, и далее циклично прогоняет их один за одним по списку с помощью Runner’а…

Накидал простенький пример с категориями на основе junit 4.12 на гитхаб:
https://github.com/bratuhin/junit-categories-example


#9

Спасибо, опишу задачу более струкрурировано.

  1. Раз в час запускается джоба, которая лезет в базу данных с ценами на товары (у каждого товара много разных цен, например аренда, купить, продать и тд), проверяет данные по товарам на отсутствие цены.
    2.Если в какой-то строке найдены одна или несколько отсутствующих цен, берет эту строку, берет данные из нее как парамертры(например код товара, url, лист с ценами, которые надо проверить(вот он динамичен, у каждого товара может отвалится 1, 2 или более цен)).
    3.Запускает с этими параметрами новую джобу на проверку (проверяем что на сайте действительно этих цен нет).
    В своем классе у меня описано в @BeforeClass мы открываем этот сайт и собираем в HashMap<String, String> prices все типы цен (ключ -тип цены, значение -сама цена).

Потом мне нужно выбрать, какие цены надо проверить, что их действительно нет. Поэтому в классе описаны несколько тестов, в каждом из которых делается проверка на No data только одной цены. И вот количество и набор этих тестов будет меняться в зависимости от входящего параметра “лист с ценами, которые надо проверить”.
Может я и накрутила, не знаю. Но принцип одна проверка в одном тесте нужно соблюдать. Я только учусь)


(Михаил Братухин) #10

Добрый день! Я всё ещё не очень понял из вашего объяснения какую именно задачу вы пытаетесь решить и почему. Мне это напомнило о проблеме X, Y и Z.
Возможно, @asolntsev меня тут “заклюет”, но думаю, что проще тут не делать один тест - одну проверку, а в рамках единого теста смотреть все цены и если в базе её нет, то проверять, что её и на сайте нет, если есть, что на сайте она тоже корректна. Тогда проблема с “динамическим” числом тестов из-за числа цен просто не будет стоять, т.к. будут проверяться все цены независимо от того есть они или их нет. Возможно я что-то не понимаю в вашей задаче.


(asolntsev) #11

Клюк-клюк!

Я тоже не понял, в чём проблема и почему.
Но да, похоже на то, что лучше сделать один тест на все случаи.