Как я могу указать тестовые зависимости от JUnit?
Наш инструментарий имеет более чем 15 000 тестов 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();
}
}
4 ответа
JExample и TestNG имеют нечто подобное.
Я не знаю, насколько это полезно, но если вы попробуете, пожалуйста, вернитесь и расскажите нам, было ли это полезно.
Вы можете объявить тестовые зависимости в TestNG , синтаксис почти такой же, как в вашем примере. Я не думаю, что JUnit предлагает что-то подобное.
В библиотеке дизайна, управляемой поведением jBehave есть ключевое слово GivenScenarios , которое импортирует список сценариев, которые запускаются перед основным сценарием. Это дает возможность определять зависимости и иметь одну точку отказа. Ведение журнала jBehave сообщит вам, не прошел ли тест в зависимостях или в основном разделе.
На самом деле я не знаю ничего подобного. (Edit: вы узнаете что-то новое каждый день :)) На мой взгляд, это не так уж и плохо (хотя я вижу, что это полезно, особенно когда JUnit используется для других форм автоматических тестов - например, интеграционные тесты). Ваши тесты, IMO, не в самом строгом смысле слова «модульные тесты» (по крайней мере, не тест для X # foo () ). Тесты для X # foo () должны быть успешными или неудачными в зависимости только от реализации X # foo () . Он не должен зависеть от Y # foo () .
На вашем месте я бы смоделировал Y и реализовал что-то вроде MockY # foo () с очень простым контролируемым поведением и использовал его в X # foo ( ) .
Тем не менее, имея 15 000 тестов, я понимаю, насколько проблематичным будет рефакторинг. :)