2015-06-05 2 views
2

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

public class MathOpTest { 
    private MathOp a; 

    @Before 
    public void setUp(){ 
     a = new MathOp(); 
    } 
    ... 
} 

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

Что-то вроде:

public class MathOpTest { 
    @TestSubject 
    private MathOp a; 
    ... 
} 

ответ

1

Вы можете назначить поля, когда они объявлены:

public class MathOpTest { 
    private final MathOp mathOp = new MathOp(); 

    ... 
} 

Это очень просто и прямолинейно, поэтому я рекомендую вам назначить поля в тестовом классе во время декларации всякий раз, когда это возможно (конечно, в случай, который вы дали).

Если вы хотите понять немного больше, читайте дальше.

  • JUnit создает уникальный экземпляр тестового класса для каждого метода испытаний, так что даже если тест изменяет внутреннее состояние MathOp, используя поля таким образом, является безопасным, пока тесты не изменяют глобальное состояние.
  • Для тестов в стиле JUnit4 (т. Е. Тестов, которые не распространяются на junit.framework.TestCase). JUnit создаст тестовый класс непосредственно перед запуском тестового метода и сделает его доступным для сбора мусора после завершения метода тестирования.

Использование методов @Before для более сложной инициализации.

Обычно я использую @Before когда:

  • Инициализация поля является сложным
  • Инициализация поля требует вызывающий код, который объявлен бросить проверяемое исключение
  • вам нужно сделать инициализацию после a @Rule (например, вводят макет в конструктор)

Обычно вы должны создать тестируемый объект в методе тестирования, когда класс должен быть сконструирован по-разному для разных вариантов использования.

Примеры

Ниже приведен пример использования @Before и initMocks():

public class MathOpTest { 
    @Mock private Calculator mockCalculator; 
    @Mock private Supplier<Double> mockPreviousResultSupplier; 
    private MathOp mathOp; 

    @Before 
    public void createMathOp() { 
    MockitoAnnotations.initMocks(this); 
    mathOp = new MathOp(
     mockCalculator, mockPreviousResultSupplier); 
    } 

    ... 
} 

Вот пример метода @Before который использует результат @Rule:

public class MyWriterTest { 
    @Rule public final TemporaryFolder folder = new TemporaryFolder(); 
    private File output; 
    private MyWriter writer; 

    @Before 
    public void createMyWriter() { 
    output = folder.newFile(); 
    writer = new MyWriter(output); 
    } 

    ... 
} 

Помимо: Я лично не рекомендовал бы использовать @InjectMocks, чтобы создать класс, который вы тестируете. На мой вкус слишком много волшебства. Наличие явного конструктора чище и проще, и мне нравятся мои тесты, чтобы быть ясными и простыми :-)

+0

Я провел много экспериментов и нашел, как вы говорите, то, что вы получили новый экземпляр класса Test для каждого теста, а не, как я думал ранее, тот же экземпляр, который использовался повторно. Был слишком занят, чтобы вернуться сюда и загрузить мои результаты, поэтому спасибо за ответ. –

+0

@ DavidNewcomb, создавая уникальный экземпляр тестового класса для каждого теста, был международным дизайнерским решением JUnit. Рад помочь! – NamshubWriter

1

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

Если вы используете Mockito, у вас действительно есть преимущества объявления класса и аннотации его @InjectMocks как для создания экземпляра класса, так и для ввода любых классов @Mock, которые у вас были до этого.

+0

Проблема 'InjectMock' и' Mock' заключается в том, что они создают mocks, и я бы хотел создать реальный экземпляр. –

+0

'@ InjectMocks' вводит издевательства в целевой объект, который создает его с помощью издевательства, который вы ранее объявили. Вы получаете реальный экземпляр тестового объекта. – Makoto

+0

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

Смежные вопросы