Заставить JUnit запускать один тестовый пример за раз

Ваша проблема не в том, что JUnit запускает все тесты одновременно, ваша проблема в том, что вы не видите, почему тест терпит неудачу. Решения:

1. Добавьте в тесты больше утверждений, чтобы убедиться, что каждая переменная действительно содержит то, что вы думаете.
2. Загрузите IDE из Интернета и используйте встроенный отладчик для просмотра различных переменных.
3. Сбросьте состояние ваших объектов непосредственно перед точкой, где тест не пройден.
4. Используйте часть «сообщение» утверждений для вывода дополнительной информации о причине сбоя (см. ниже).
5. Отключите все тесты, кроме нескольких (в JUnit 3: замените все строки «void test» на «void dtest» в исходном коде; в JUnit 4: замените «@Test» на «//D@TEST»).

Пример:

assertEquals(list.toString(), 5, list.size());

Я в курсе всех рекомендаций, но, чтобы наконец ответить на ваш вопрос, вот простой способ добиться того, чего вы хотите. Просто поместите этот код в тестовый пример:

Lock sequential = new ReentrantLock();

@Override
protected void setUp() throws Exception {
    super.setUp();
    sequential.lock();
}

@Override
protected void tearDown() throws Exception {
    sequential.unlock();
    super.tearDown();
}

При этом ни один тест не может начаться, пока не будет получена блокировка, и одновременно может быть получена только одна блокировка.

Создается впечатление, что ваши тест-кейсы зависимы, то есть: выполнение кейса-X влияет на выполнение кейса-Y. Такой системы тестирования следует избегать (например: нет гарантии порядка, в котором JUnit будет запускать ваши случаи).

Вы должны реорганизовать свои дела, чтобы сделать их независимыми друг от друга. Во многих случаях использование методов @Before и @After может помочь вам распутать такие зависимости.

Поздравляем. Вы нашли ошибку. ;-)

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

Извините, если я не отвечу на ваш вопрос напрямую, но разве ваша проблема не связана с тем, что должны решать TestCase.setUp() и TestCase.tearDown()? Это методы, которые среда JUnit всегда будет вызывать до и после каждого тестового примера, и обычно они используются для обеспечения того, чтобы вы начинали каждый тестовый пример в одном и том же состоянии.

См. также JavaDoc для TestCase.

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

Maven и Ant содержат параметр forkmode для запуска тестов JUnit, который указывает, получает ли каждый тестовый класс свою собственную JVM или все тесты выполняются в одной JVM. Но у них нет возможности запускать каждый тестовый метод на отдельной JVM.

Я знаю о проблеме зависимых тестовых случаев, но я не могу точно определить, почему это так. В тестовых примерах нет сохраненных переменных, поэтому в аннотации @Before делать нечего. Вот почему я ищу экстренное решение, например, заставить JUnit запускать тесты по отдельности.

Оператор @Before безвреден, потому что он вызывается для каждого теста. Класс @BeforeClass опасен, потому что он должен быть статическим.

Мне кажется, что, возможно, дело не в том, что вы неправильно настраиваете или удаляете свои тесты (хотя дополнительная настройка/удаление может быть частью решения), а в том, что, возможно, у вас есть общее состояние в вашем коде, которым вы не являетесь. в курсе. Если ранний тест устанавливает статическую/одиночную/общую переменную, о которой вы не знаете, более поздние тесты потерпят неудачу, если они этого не ожидают. Даже с Mocks это очень возможно. Вам нужно найти эту причину. Я согласен с другими ответами в том, что ваши тесты выявили проблему, которую не следует решать, пытаясь запустить тесты по-другому.

Ваше описание показывает мне, что ваши модульные тесты зависят друг от друга. Это настоятельно не рекомендуется в модульных тестах.

Модульный тест должен быть независимым и изолированным. Вы должны быть в состоянии выполнить их в одиночку, все (в каком порядке, это не имеет значения).

Я знаю, это тебе не поможет. Проблема будет в ваших утверждениях @BeforeClass или @Before. Будут зависимости. Поэтому проведите их рефакторинг и попытайтесь изолировать проблему.

Вероятно, ваши макеты создаются в вашем файле @BeforeClass. Подумайте о том, чтобы поместить его в оператор @Before. Таким образом, нет экземпляра, который длится дольше, чем тестовый пример.