Как я могу указать тестовые зависимости JUnit?

Question

Наш инструментарий имеет более 15000 JUnit тестов, и многие тесты, как известно, не проходят, если какой-либо другой тест не пройден. Например, если метод X.foo () использует функциональность из Y.bar () и YTest.testBar () завершается ошибкой, то XTest.testFoo () также завершится ошибкой. Очевидно, что XTest.testFoo () также может завершиться ошибкой из-за проблем, специфичных для X.foo ().

Хотя это нормально, и я все еще хочу, чтобы оба теста выполнялись, было бы хорошо, если бы можно было аннотировать зависимость теста с помощью XTest.testFoo (), указывающей на YTest.testBar (). Таким образом, можно сразу увидеть, какая функциональность, используемая X.foo (), также не работает, а какая нет.

Есть ли такая аннотация в JUnit или где-либо еще? Что-то вроде:

public XTest {

  @Test
  @DependsOn(method=org.example.tests.YTest#testBar)
  public void testFoo() {
     // Assert.something();
  }

}

Answer 1

JExample и TestNG имеют что-то подобное.

Не знаю, насколько это полезно, но если вы попробуете это, пожалуйста, вернитесь, чтобы сказать нам, было ли это полезно.

Answer 2

Есть вклад в JUnit, который адресует это: https://github.com/junit-team/junit.contrib/tree/master/assumes

Answer 3

org.junit.FixMethodOrder

@ FixMethodOrder (MethodSorters.NAME_ASCENDING) Это относится к вашему классу модульных тестов.

Вы можете назвать ваши методы public void step1_methodName и т. Д.

Answer 4

Вы можете объявить тестовые зависимости в TestNG , синтаксис практически такой же, как в вашем примере. Я не думаю, что JUnit предлагает нечто подобное.

Answer 5

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

Answer 6

На самом деле я не знаю ничего подобного. (Правка: вы узнаете что-то новое каждый день :)) На мой взгляд, это не так уж плохо ( хотя я вижу, что это полезно, особенно когда JUnit используется для других форм автоматических тестов - например, интеграционных тестов). Ваши тесты, IMO, не в самом строгом смысле слова «модульные тесты» (по крайней мере, не тест для X#foo()). Тесты для X#foo() должны быть успешными или неуспешными в зависимости от только от реализации X#foo(). Он не должен зависеть от Y#foo().

Что бы я на вашем месте сделал, это смоделировал Y и реализовал что-то вроде MockY#foo() с очень простым, контролируемым поведением и использовал его в тестах X#foo().

Тем не менее, с 15 000 тестов, я могу видеть, как это было бы болезненно для рефакторинга. :)