Как переделать параметризованный тест на JUnit в TestNG

программирование java
, , ,
#1

Здравствуйте.
Есть такой код с JUnit.
Появилась необходимость перейти на TestNG.

Описание:
Мы хаваем .txt с кучей URL. Дальше мы передаем этот URL в тест. Каждый новый URL генерит новый тест. Для отчетов используется Allure
Вопрос:
Подскажите пожалуйста как переписать данный код под TestNG.

@RunWith(Parameterized.class)
public class ajaxTest {
    testStatus status = new testStatus();

    @Parameterized.Parameters(name = "url = {0}")
    public static Collection<Object[]> parameters() throws IOException {

        BufferedReader reader = new BufferedReader(new FileReader("./urls.txt"));
        List<String> urls = new ArrayList<>();
        while ((url = reader.readLine()) != null) {
            urls.add(url);
        }
        return urls.stream().map(url -> new String[]{url}).collect(Collectors.toList());
    }

    @Parameterized.Parameter
    public static String url;

    @Severity(SeverityLevel.BLOCKER)
    @Test
    public void status() throws IOException {
        status.testStatus(url);
    }
}
#2

Остановитесь, пока не поздно!
Не переходите на TestNG! Это зло!
В нём нет ни одной хорошей фичи, которой бы не было в JUnit.

1 лайк
#3

Плюс выходит JUnit 5

#4

У меня 2 теста подобных только. Я решил не писать свой “параметризатор”, а просто foreach цикл использовать

void parTests()
for(String value : values){
/*сценарий какой-то*/
}

А values это список/массив/коллекция, который можно слепить из чего угодно! Что несомненно приятно

Может это и не правильно - но проще решения не придумать.

А testNG, по личному опыту мне не понравился, субъективно не стабильный, субъективно не однозначный, и т.д. :slight_smile:

#5

Я пока не читал про JUnit 5.
Если он будет подходить под наши требования, то вернуться всегда можно :slight_smile:

#6

Я думаю, как-то так:

#7

Какие такие у вас требования?
Почему TestNG подходит, а JUnit 4 не подходит?

(сомневаюсь, что JUnit 5 что-то изменит в этом плане)

#8

Неужели в Junit уже завезли удобные паралельные запуски из дата провайдеров ?

1 лайк
#9

Нет, такого нет, но это и не надо.
Это какое-то зло злющее, жутко сложно. Можно ведь всё гораздо проще делать.
Да и вообще свои требования пересмореть. Не нужно вам это.

#10

Дизлайк :slight_smile: Норм все, пусть пишет)
Вот настроить Аллур - зло :slight_smile: пока разберешься в нем…

#11

Используйте DataProvider TestNG

Пример:

@Test(dataProvider = "setOfUrls")
public void testMyParams(String url){
  //... do test code. For example, System.out.println(url);
}
//....
@DataProvider
public Object[][] setOfUrls(){
  return new Object[][]{
      {"http://ya.ru"},
      {"http://google.com"},
      {"http://bint.com"},
  }
}
#12

почему вы так против TestNG?

#13

Ну, я же написал:

В нём нет ни одной хорошей фичи, которой бы не было в JUnit.

Зато в нём есть вредные фичи и есть баги.
Я давно хочу написать об этом отдельный пост, да всё руки не доходят… :frowning:

#14

ну было бы здорово почитать пост, постарайтесь найти времечко. :slight_smile: Потому что мне как-то удобней с ним работать в разы. Особенно очень удобно работать с xml-кой и группировать тесты. Можно создавать разные сьюты и дергать их в зависимости от необходимости…

да и вот такие штуки бывают полезными:

  • запуск перед сьютом
  • запуск после сьюта
  • запуск перед тестированием
  • запуск после тестирования
  • запуск перед тестом из группы
  • запуск после теста из группы

уже жду не дождусь вот этого доклада - JUnit vs TestNG! Нужна помощь от коммьюнити :slight_smile:

#15

Ну так в JUnit можно тоже тестам давать тэги и категории. По-моему, это гораздно удобнее, чем создавать сьюиты. Просто говоришь: “Запусти все тесты, связанные с платежами” - и фигак, JUnit сам нашёл и запустил все тесты с тэгом “payments”. И не надо никаких XML и сьюитов вручную создавать.

#16

А если надо все тесты с платежками, кроме некоторых? Там достаточно просто строку в сьюте закоментировать или написать исключение. Наверное все же дело вкуса… Но статейку бы читнул с удовольствием :slight_smile:

Тема давняя, очень часто встречаю сторонников jUnit и TestNG.

Единственное, что в jUnit видел удобнее, так это - Ignore тесты | Trial book, но все же это такая мелочь, можно и комментарий сверху написать…

Также @DataProvider может передавать в тест данные любого типа. Мне как-то это очень помогло

Возможно для юнит-тестов - более чем достаточно jUnit, а для автоматизации - TestNG, хотя и jUnit с этим тоже справляется…

Единственное, что опасно в TestNG - это делать зависимые тесты, это скорей всего лучше стороной обходить, а не использовать как полезную фичу и проектировать тесты как-то так, чтобы такого небыло, в остальном очень даже все удобненько…

#17

Для этого есть groups в TestNG, а далее - или surefire плагин в Maven, или testNG настройка в Gradle. Никаких XML не требуется, только указать, к примеру, -Dgroups=group1,group2. В таком случае запустятся тесты входящие в группу group1 или group2

#18

А зачем это надо?
Если хорошенько задуматься, это не нужно! А если нужно, это свидетельствует о более серьёзных проблемах в проекте.

Ну и кстати, так же легко закомментировать “ненужные” тесты.

О, нет-нет. Совсем наоборот. @DataProvider если и нужен, то как раз для юнит-тестов. Потому, что они по определению быстрые, и в них можно проверить кучу разных комбинаций. А UI-тесты по определению медленные, и в них нельзя проверять кучу комбинаций. Только один-два-три самых критичных сценария. И для этого не нужны @DataProvider.

Да, точно, это то самое зло, которое я имел в виду.

1 лайк
#19

А что ещё за теги? я только категории нашел.

#20

Ну да, верно, категории.