Самый простой (как минимум необходимый объем нового кода) способ сделать это - запустить тест как параметризованный (пометить @RunWith(Parameterized.class)
и добавить метод для предоставления 10 пустых параметров). Таким образом, фреймворк выполнит тест 10 раз.
Этот тест должен быть единственным тестом в классе, или, лучше сказать, все методы тестирования должны выполняться в классе 10 раз.
Вот пример:
@RunWith(Parameterized.class)
public class RunTenTimes {
@Parameterized.Parameters
public static Object[][] data() {
return new Object[10][0];
}
public RunTenTimes() {
}
@Test
public void runsTenTimes() {
System.out.println("run");
}
}
С вышесказанным можно даже сделать это с помощью конструктора без параметров, но я не уверен, предполагали ли это авторы фреймворка или это сломается в будущем.
Если вы реализуете свой собственный бегун, то вы можете запустить тест 10 раз. Если вы используете сторонний бегун, то с 4.7 вы можете использовать новую @Rule
аннотацию и реализовать MethodRule
интерфейс так, чтобы он принимал оператор и выполнял его 10 раз в цикле for. Текущий недостаток такого подхода в том, что @Before
и @After
запускается только один раз. Скорее всего, это изменится в следующей версии JUnit ( @Before
будет запускаться после @Rule
), но независимо от того, что вы будете действовать с одним и тем же экземпляром объекта (что не относится к Parameterized
бегуну). Это предполагает, что любой бегун, с которым вы запускаете класс, правильно распознает @Rule
аннотации. Это только в том случае, если он делегируется исполнителям JUnit.
Если вы работаете с настраиваемым бегуном, который не распознает @Rule
аннотацию, то вам действительно приходится писать собственный бегун, который надлежащим образом делегирует этому бегуну и запускает его 10 раз.
Обратите внимание, что есть и другие способы решения этой проблемы (например, бегун Theories), но все они требуют бегуна. К сожалению, JUnit в настоящее время не поддерживает уровни бегунов. Это бегун, который сковывает других бегунов.