Неисследованные тесты

Question

При запуске всех моих тестов в Eclipse (Eclipse 3.4 «Ganymede») один тест указывается в разделе «Unrooted Tests». Я использую Junit 3.8, и этот конкретный тест расширяет TestCase. Я не вижу разницы между этим тестом и другими тестами. Я не помню, чтобы это происходило в Eclipse 3.3 (Европа).

Пояснение:

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

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

Я согласен, это похоже на проблему Eclipse.

Answer 1

Другим сценарием, который вызывает эту проблему, было слепое копирование / вставка метода, для которого требуется параметр . т.е.

import org.junit.Test;

public class MyTest {

    @Test
    public void someMethod(String param) {
          // stuff
    }

}

У вас есть несколько простых решений:

1. определить переменную в конкретном методе теста

2. добавить его в качестве переменной экземпляра в тестовый класс

3. создайте метод настройки и аннотируйте его с помощью @Before

Answer 2

Оказалось, что у моего пути сборки была какая-то ошибка ... некоторые банки отсутствовали. Я перенастроил путь сборки, и он заработал!

Answer 3

Еще одна вещь, которую вы можете попробовать - обновить версию JUnit до версии не ниже 4.12.

Я какое-то время испытывал эту проблему с классом, который расширил класс, использующий @RunWith (Parameterized.class).

Через некоторое время, и я извиняюсь, что не знаю точно, что я сделал, чтобы вызвать это, сообщение «Unrooted Tests» исчезло, но тест все еще не работал правильно. Конструктор, который должен был принимать аргументы от метода @Parameters, никогда не вызывался; выполнение переместилось прямо с @BeforeClass на @ AfterClass.

Решением этой проблемы было обновление JUnit с версии 4.8.1, которую он использовал, до последней версии (4.12). Так что, возможно, это могло бы помочь кому-то еще в будущем.

Answer 4

Я столкнулся с этой проблемой, также не объявляя тест static.

Answer 5

Я получил эту ошибку с именем метода теста как «тест»

@Test 
public void test() {
 // ... assertTrue(1 == 1); 
}

Я переименовал метод, и он работал

Answer 6

Я мог бы решить эту проблему, переключившись с TestRunner версии 4.0 на 3 в конфигурациях прогона для отдельного метода тестирования.

Answer 7

Не расширяйте junit.framework.TestCase в вашем тестовом классе с помощью junit1.4, и это должно решить проблему

Answer 8

Может быть, это просто логическая путаница относительно цели метода. Давайте вспомним:

например. правильный помеченный метод испытания:

@Test
@Transactional
@Rollback(true)
public void testInsertCustomer() {  
    (...)
}

- С плагином Eclipse Junit этот метод тестирования можно запустить с помощью контекстного меню поверх метода (например, в проводнике пакетов, расширяя класс и методы и выбирая метод «testInsertCustomer ()», а из этого элемента выбирая «Запуск от имени >> Юнит тест ").

Если вы забыли тег «@Test» или просто метод является не тестом, а (частным или нет) общим методом для использования в качестве утилиты для других тестов (например, «private fillCustomerObject ()»), тогда Метод не требует тега "@Test", просто вы не можете запустить его как тест JUnit!

Легко, что вы можете создать служебный метод, а позже вы забыли реальную цель этого метода, поэтому, если вы попытаетесь запустить его как тест, JUnit выкрикнет «Unrooted Tests».

Answer 9

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

import static org.junit.Assert.*;

Проверьте, используете ли вы в своем тесте:

import static org.hamcrest.MatcherAssert.assertThat;

или другое утверждение не является утверждением.

Answer 10

Для меня эта проблема возникла из-за исключения в реальном времени, сгенерированного в методе @AfterClass (посмотрите документацию здесь ):

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