JUnit 4 Vs TestNG - Сравнение

JUnit 4 против TestNG - Сравнение

JUnit 4 и TestNG являются очень популярными средами модульного тестирования в Java. Оба фреймворка очень похожи по функциональности. Какой из них лучше? Какую среду модульного тестирования я должен использовать в проекте Java?

Здесь я провел сравнение функций JUnit 4 и TestNG.

junit-vs-testngjpg

1. Поддержка аннотаций

Поддержка аннотаций реализована как в JUnit 4, так и в TestNG.

Особенность JUnit 4 TestNG

тестовая аннотация

@Тестовое задание

@Тестовое задание

запустить до того, как все тесты в этом наборе будут запущены

@BeforeSuite

запустить после выполнения всех тестов в этом наборе

@AfterSuite

запустить перед тестом

@BeforeTest

бежать после теста

@AfterTest

запускается перед вызовом первого тестового метода, принадлежащего любой из этих групп

@BeforeGroups

запускается после вызова последнего тестового метода, принадлежащего любой из этих групп

@AfterGroups

запускается перед вызовом первого тестового метода в текущем классе

@BeforeClass

@BeforeClass

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

@После школы

@После школы

запускать перед каждым методом тестирования

@До

@BeforeMethod

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

@После

@AfterMethod

игнорировать тест

@ignore

@Test (enbale = ложь)

ожидаемое исключение

@Test (ожидается = ArithmeticException.class)

@Test (ожидаемые исключения = ArithmeticException.class)

Тайм-аут

@Test (тайм-аут = 1000)

@Test (тайм-аут = 1000)

Основные различия аннотаций между JUnit4 и TestNG:

1. В JUnit 4 мы должны объявить методы «@BeforeClass» и «@AfterClass» как статические. TestNG более гибок в объявлении методов, у него нет этих ограничений.

2. 3 дополнительных уровня setUp / tearDown: набор и группа (@ Before / AfterSuite, @ Before / AfterTest, @ Before / AfterGroup). Посмотреть большеdetail here.

JUnit 4

    @BeforeClass
    public static void oneTimeSetUp() {
        // one-time initialization code
        System.out.println("@BeforeClass - oneTimeSetUp");
    }

TestNG

    @BeforeClass
    public void oneTimeSetUp() {
        // one-time initialization code
        System.out.println("@BeforeClass - oneTimeSetUp");
}

В JUnit 4 соглашение об именах аннотаций немного сбивает с толку, например, «До», «После» и «Ожидается», мы действительно не понимаем, что делают «До» и «После» и чего «ожидали» от теста. метод? TestiNG легче понять, вместо этого он использует «BeforeMethod», «AfterMethod» и «ExpectedException».

2. Исключительный тест

«Тестирование исключений» означает, какое исключение выбрасывает модульный тест. Эта функция реализована как в JUnit 4, так и в TestNG.

JUnit 4

      @Test(expected = ArithmeticException.class)
    public void divisionWithException() {
      int i = 1/0;
    }

TestNG

      @Test(expectedExceptions = ArithmeticException.class)
    public void divisionWithException() {
      int i = 1/0;
    }

3. Игнорировать тест

«Игнорировано» означает, следует ли игнорировать модульный тест, эта функция реализована как в JUnit 4, так и в TestNG.

JUnit 4

        @Ignore("Not Ready to Run")
    @Test
    public void divisionWithException() {
      System.out.println("Method is not ready yet");
    }

TestNG

    @Test(enabled=false)
    public void divisionWithException() {
      System.out.println("Method is not ready yet");
    }

4. Тест времени

«Тест времени» означает, что если выполнение модульного теста занимает больше указанного количества миллисекунд, тест будет завершен и помечен как неудачный, эта функция реализована как в JUnit 4, так и в TestNG.

JUnit 4

        @Test(timeout = 1000)
    public void infinity() {
        while (true);
    }

TestNG

    @Test(timeOut = 1000)
    public void infinity() {
        while (true);
    }

5. Suite Test

«Suite Test» означает объединить несколько модульных тестов и запустить их вместе. Эта функция реализована как в JUnit 4, так и в TestNG. Однако оба используют совершенно разные методы для его реализации.

JUnit 4

«@RunWith» и «@Suite» используются для запуска теста пакета. Приведенный ниже класс означает, что оба модульных теста «JunitTest1» и «JunitTest2» выполняются вместе после выполнения JunitTest5. Все объявления определяются внутри класса.

@RunWith(Suite.class)
@Suite.SuiteClasses({
        JunitTest1.class,
        JunitTest2.class
})
public class JunitTest5 {
}

TestNG

XML-файл используется для запуска теста пакета. Приведенный ниже XML-файл означает, что оба модульных теста «TestNGTest1» и «TestNGTest2» будут запускать его вместе.



  
    
       
       
    
  

TestNG может делать больше, чем тестирование классов пакетов, он также может объединять тестирование методов. Благодаря уникальной концепции «группировки» TestNG, каждый метод привязан к группе, он может классифицировать тесты по функциям. Например,

Вот класс с четырьмя методами, тремя группами (метод1, метод2 и метод3)

        @Test(groups="method1")
    public void testingMethod1() {
      System.out.println("Method - testingMethod1()");
    }

    @Test(groups="method2")
    public void testingMethod2() {
        System.out.println("Method - testingMethod2()");
    }

    @Test(groups="method1")
    public void testingMethod1_1() {
        System.out.println("Method - testingMethod1_1()");
    }

    @Test(groups="method4")
    public void testingMethod4() {
        System.out.println("Method - testingMethod4()");
    }

С помощью следующего XML-файла мы можем выполнить модульный тест только с группой «method1».



  
    
      
        
      
    
    
       
    
  

С концепцией тестирования «Группировка» возможности интеграционного тестирования безграничны. Например, мы можем протестировать только группу «DatabaseFuntion» из всех классов модульного тестирования.

6. Параметризованный тест

«Параметризованный тест» означает изменение значения параметра для модульного теста. Эта функция реализована как в JUnit 4, так и в TestNG. Однако оба используют совершенно разные методы для его реализации.

JUnit 4

«@RunWith» и «@Parameter» используются для предоставления значения параметра для модульного теста, @Parameters должен возвращать List [], а параметр передается в конструктор класса в качестве аргумента.

@RunWith(value = Parameterized.class)
public class JunitTest6 {

     private int number;

     public JunitTest6(int number) {
        this.number = number;
     }

     @Parameters
     public static Collection data() {
       Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
       return Arrays.asList(data);
     }

     @Test
     public void pushTest() {
       System.out.println("Parameterized Number is : " + number);
     }
}

Здесь много ограничений; мы должны следовать способу «JUnit» для объявления параметра, и параметр должен быть передан в конструктор, чтобы инициализировать член класса как значение параметра для тестирования. Тип возврата класса параметра - «Список []», данные были ограничены строкой или примитивным значением для тестирования.

TestNG

XML-файл или «@DataProvider» используется для предоставления параметра переменной для тестирования.

XML file for parameterized test.
Только «@Parameters» объявляет в методе, которому требуется параметр для тестирования, параметрические данные будут предоставлены в файлах конфигурации TestNG XML. Таким образом мы можем повторно использовать один тестовый пример с разными наборами данных и даже получить разные результаты. Кроме того, даже конечный пользователь, QA или QE может предоставить свои собственные данные в файле XML для тестирования.

Модульный тест

      public class TestNGTest6_1_0 {

       @Test
       @Parameters(value="number")
       public void parameterIntTest(int number) {
          System.out.println("Parameterized Number is : " + number);
       }

      }

XML-файл



  

    

    
       
    
  

@DataProvider для параметризованного теста.

Хотя извлечение значений данных в файл XML может быть весьма удобным, для тестов иногда требуются сложные типы, которые не могут быть представлены как String или примитивное значение. TestNG обрабатывает этот сценарий с помощью аннотации @DataProvider, которая упрощает сопоставление сложных типов параметров с методом тестирования.

@DataProvider для вектора, строки или целого числа в качестве параметра

        @Test(dataProvider = "Data-Provider-Function")
    public void parameterIntTest(Class clzz, String[] number) {
       System.out.println("Parameterized Number is : " + number[0]);
       System.out.println("Parameterized Number is : " + number[1]);
    }

    //This function will provide the patameter data
    @DataProvider(name = "Data-Provider-Function")
    public Object[][] parameterIntTestProvider() {
        return new Object[][]{
                   {Vector.class, new String[] {"java.util.AbstractList",
"java.util.AbstractCollection"}},
                   {String.class, new String[] {"1", "2"}},
                   {Integer.class, new String[] {"1", "2"}}
                  };
    }

@DataProvider для объекта в качестве параметра
P.S «TestNGTest6_3_0» - это простой объект с методом только получения set для демонстрации.

        @Test(dataProvider = "Data-Provider-Function")
    public void parameterIntTest(TestNGTest6_3_0 clzz) {
       System.out.println("Parameterized Number is : " + clzz.getMsg());
       System.out.println("Parameterized Number is : " + clzz.getNumber());
    }

    //This function will provide the patameter data
    @DataProvider(name = "Data-Provider-Function")
    public Object[][] parameterIntTestProvider() {

        TestNGTest6_3_0 obj = new TestNGTest6_3_0();
        obj.setMsg("Hello");
        obj.setNumber(123);

        return new Object[][]{
                   {obj}
        };
    }

Параметризованный тест TestNG очень удобен и гибок (в файле XML или внутри класса). Он может поддерживать многие сложные типы данных в качестве значений параметра, и возможность неограничена. Как пример выше, мы даже можем передать наш собственный объект (TestNGTest6_3_0) для параметризованного теста

7. Тест на зависимость

«Параметризованный тест» означает, что методы являются тестовой базой на зависимости, которая будет выполняться перед желаемым методом. Если зависимый метод дает сбой, все последующие тесты будут пропущены и не помечены как неудачные.

JUnit 4

Фреймворк JUnit ориентирован на изоляцию тестов; в настоящий момент он не поддерживает эту функцию.

TestNG

Он использует «dependsOnMethods» для реализации тестирования зависимостей следующим образом

        @Test
    public void method1() {
       System.out.println("This is method 1");
    }

    @Test(dependsOnMethods={"method1"})
    public void method2() {
        System.out.println("This is method 2");
    }

«Method2 ()» будет выполняться только в случае успешного выполнения «method1 ()», иначе «method2 ()» пропустит тест.

Заключение

Поразмыслив над сравнением всех функций, я предлагаю использовать TestNG в качестве основы модульного тестирования для проекта Java, потому что TestNG более продвинут в параметризации тестирования, тестирования зависимостей и тестирования набора (концепция группировки). TestNG предназначен для высокоуровневого тестирования и комплексного интеграционного тестирования. Его гибкость особенно полезна для больших наборов тестов. Кроме того, TestNG также охватывает всю базовую функциональность JUnit4. У меня больше нет причин использовать JUnit.