Статьи

Это материал: jUnit: генерация динамических тестов

Январь 2, 2019

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

Теории полезны, когда у вас есть набор данных, которые будут использоваться в качестве параметров, и вы хотите запустить тесты для всех их комбинаций. Вы получаете меньше контроля, но вам не нужно самостоятельно писать комбинирующий и повторяющийся код. Основы о том, как работают теории, объясняются вундеркиндами Java-кода (оригинал в Java-календаре появления ), поэтому этот пост посвящен параметризованным тестам.

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

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

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

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

Пример использования

Less4j меньше для компилятора css, поэтому каждый из его тестов определяется файлом без ввода и ожидаемым файлом css. Компилятор запускается на входном файле, и его вывод сравнивается с ожидаемым CSS. Если они совпадают, тест пройден.

Все файлы .less хранятся в каталоге. Параметризованный тестовый пример считывает этот каталог и создает один тест jUnit для каждого файла. Поэтому мы можем добавить новые тесты, просто создав новые .less и .css, запустить тесты с помощью кнопки «выполнить все» и увидеть новый тест во всех отчетах.

Как это использовать

Параметризованный тестовый набор должен иметь следующие вещи:

  • аннотация класса @RunWith(Parameterized.class) ,
  • конструктор, который принимает параметры тестового примера,
  • статический метод с аннотацией @Parameters для генерации параметров,
  • методы тестирования, которые запускаются на параметрах, предоставленных в конструкторе.

Конструктор

Параметризованный конструктор должен иметь хотя бы один параметр. Например, тестовый пример компилятора может принимать input меньше в качестве первого аргумента, а ожидаемый скомпилированный css — в качестве второго аргумента. Имя третьего аргумента игнорируется и будет объяснено позже:

1
2
3
4
5
6
7
8
9
@RunWith(Parameterized.class)
public class ParametrizedTest {
 
  public ParametrizedTest(String less, String expectedCss, String name) {
    this.less = less;
    this.expectedCss = expectedCss;
  }
 
}

параметры

Статический метод, генерирующий параметры, должен возвращать реализацию интерфейса Iterable . Итератор возвращает массивы, содержащие наборы параметров. Каждый массив используется для создания одного экземпляра тестового примера, а объекты в нем используются в качестве параметров конструктора.

Например, следующий метод возвращает два массива и, таким образом, приводит к двум экземплярам тестового примера:

1
2
3
4
5
6
7
@Parameters(name="Name: {2}")
public static Iterable<Object[]> generateParameters() {
  List<Object[]> result = new ArrayList<Object[]>();
  result.add(new Object[] {"less", "css", "pass"});
  result.add(new Object[] {"less", "error", "fail"});
  return result;
}

Параметр аннотации name является необязательным. Его значение будет показано в графическом интерфейсе или в отчете maven в качестве имени тестового примера. {n} является заполнителем для n-го значения массива. Они индексируются от 0, поэтому первый тестовый случай будет называться Name: pass а второй тестовый случай будет называться Name: fail .

Методы испытаний

Параметризованный тестовый @Test может иметь любое количество тестов, и они должны быть @Test аннотацией @Test :

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
@Test
public void testCss() { //dummy test method
  String actualCss = compile(less);
  assertEquals(expectedCss, actualCss);
}
 
@Test
public void testSourceMap() { //another test method
  String actualCss = compile(less);
  assertEquals(expectedCss, actualCss);
}
 
private String compile(String less) { //dummy compile method
  return "css";
}

Выход

Если вы запустите вышеупомянутый тестовый класс, представление JUnit покажет следующую структуру:

1
2
3
4
5
6
7
[F] com.github.sommeri.jUnit4Examples.ParametrizedTest
[ ] |-- [Name: pass]
[ ] |---------------- testCss[Name: pass]
[ ] |---------------- testSourceMap[Name: pass]
[F] |-- [Name: fail]
[F] |---------------- testCss[Name: fail]
[F] |---------------- testSourceMap[Name: fail]

Полный тестовый кейс

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
@RunWith(Parameterized.class)
public class ParametrizedTest {
   
  private String less;
  private String expectedCss;
 
  public ParametrizedTest(String less, String expectedCss, String name) {
    this.less = less;
    this.expectedCss = expectedCss;
  }
   
  @Parameters(name="Name: {2}")
  public static Iterable<Object[]> generateParameters() {
    List<Object[]> result = new ArrayList<Object[]>();
    result.add(new Object[] {"less", "css", "pass"});
    result.add(new Object[] {"less", "error", "fail"});
    return result;
  }
   
  @Test
  public void testCss() {
    String actualCss = compile(less);
    assertEquals(expectedCss, actualCss);
  }
 
  @Test
  public void testSourceMap() {
    String actualCss = compile(less);
    assertEquals(expectedCss, actualCss);
  }
 
  //dummy compile method
  private String compile(String less) {
    return "css";
  } 
}
Ссылка: Это материал: jUnit: генерация динамических тестов от нашего партнера по JCG Марии Юрковичовой из блога This is Stuff .
35
Share: