Почему JUnit запускает тестовые случаи для теории только до первого сбоя?

Question

Недавно в JUnit была добавлена ​​новая концепция Теории (начиная с версии 4.4).

В двух словах, вы можете пометить свой метод тестирования аннотацией @Theory (вместо@Test), задайте параметризацию вашего тестового метода и объявите массив параметров, помеченных @DataPoints аннотацией где-то в том же классе.

JUnit будет последовательно запускать ваш параметризованный метод тестирования, передавая параметры, полученные из @DataPoints один за другим.Но только до тех пор, пока первый такой вызов не завершится неудачей (по любой причине).

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

Итак, мне интересно, в чем причина не выполнять @Theory помеченный метод для каждого @DataPoint?(Кажется, что не так сложно унаследовать от Theories runner и создать собственный runner, который будет игнорировать сбои, но почему у нас нет такого поведения из коробки?)

UPD : Iсоздали отказоустойчивую версию бегуна Теорий и сделали ее доступной для общего доступа: https://github.com/rgorodischer/fault-tolerant-theories

Чтобы сравнить ее со стандартным бегуном Теорий, запустите StandardTheoriesBehaviorDemo, а затем FaultTolerantTheoriesBehaviorDemo, которые находятся в папке src/test/...,

Answer 1

Сообщение о нескольких сбоях в одном тесте, как правило, является признаком того, что тест делает слишком много, по сравнению с тем, что должен делать модульный тест. Обычно это означает, что тест действительно функциональный / приемочный / потребительский тест или, если это модульный тест, то он слишком большой юнит-тест.

JUnit лучше всего работает с рядом небольших тестов. Это выполняет каждый тест в отдельном экземпляре класса теста. Это сообщает о неудаче на каждом тесте. Общий код установки наиболее естественен, когда разделение между тестами. Это дизайнерское решение, которое пронизывает JUnit, и когда вы решите сообщить о нескольких сбоях за тест, вы начинаете бороться с Юнитом. Это не рекомендуется.

Длительные испытания являются запахом дизайна и указывают на вероятность дизайна проблема. Кент Бек любит говорить в этом случае, что "есть возможность узнать что-то о вашем дизайне. "Мы хотели бы увидеть шаблон языка вокруг этих проблем, но он не имеет еще не было записано. Источник: http://junit.sourceforge.net/doc/faq/faq.htm#tests_12

Чтобы игнорировать ошибки подтверждений, вы также можете использовать правило сбора ошибок JUnit:

Правило ErrorCollector позволяет продолжить выполнение теста после первая проблема найдена (например, собрать все неверные строк в таблице и сообщать обо всех сразу)

Например, вы можете написать такой тест.

public static class UsesErrorCollectorTwice {
  @Rule
  public ErrorCollector collector= new ErrorCollector();

  @Test
  public void example() {
    String x = [..]
    collector.checkThat(x, not(containsString("a")));
    collector.checkThat(y, containsString("b"));             
  }
}

Сборщик ошибок использует Matcher Hamcrest. В зависимости от ваших предпочтений это положительно или нет.

Answer 2

AFAIK, идея та же, что и с утверждениями, первый сбой останавливает тест. В этом разница между параметризованными и теориями.

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

Попробуйте посмотреть Параметризованный . Может быть, это обеспечивает то, что вы хотите.

Answer 3

Теория неверна, если один тест в ней неверен, согласно определению Теории. Если ваши тесты не соответствуют этому правилу, было бы неправильно называть их «Теорией».