Вызов метода JUnit assertTrue(), не хватает ли объекта?

Question

Я учусь JUnit, но не assertTrue (..) можно использовать следующим образом:

anObject myObject=anObject(); 
myObject.assertTrue(...); 

Часть я не совсем понимаю, это, в ОО-языке, где вдруг приходит этот вызов метода без объекта, кажется, это подразумевает JUnit.assertTrue (...), вот как я это понимаю, но об этом нигде не упоминается, я прав?

Если это так, тогда «Результат результата = JUnitCore.runClasses (TestJunit.class);» должно быть таким:

Result result = runClasses(TestJunit.class); 

Почему непоследовательность? Я что-то упускаю ?

Answer 1

Во-первых, assertTrue и его родственники (assertFalse, assertThat) - это все статические методы. Можно было бы импортировать статический метод их утверждения выбора (и который живет в Assert, поэтому assertTrue является сокращением для Assert.assertTrue).

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

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

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

Use case: Я написал утилиту для извлечения заданной разницы между двумя Lists с очевидным предупреждением о наличии дубликатов. Это какой-то код, который я помню, чтобы собрать еще один ответ, но мне понравилось, что я его уточнил, и написал тесты для обеспечения поведения.

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

@Test 
public void testDifference() throws Exception { 
    //given 
    List<Integer> left = Lists.newArrayList(1, 2, 3, 4, 5); 
    List<Integer> right = Lists.newArrayList(1, 2, 4, 5); 

    //when 
    List<Integer> result = SetUtils.difference(left, right); 

    //then 
    assertEquals(Lists.newArrayList(3), result); 
} 

@Test 
public void testDifference2() throws Exception { 
    //given 
    List<Integer> left = Lists.newArrayList(1, 2, 3, 4, 5, 6, 7, 9, 10); 
    List<Integer> right = Lists.newArrayList(1, 2, 4, 5, 10); 

    //when 
    List<Integer> result = SetUtils.difference(left, right); 

    //then 
    assertEquals(Lists.newArrayList(3, 6, 7, 9), result); 
} 

---

Если вы по-прежнему вниз далеко, позвольте мне проиллюстрировать одно из преимуществ для написания модульных тестов в этом поведении. Если бы я хотел отказаться от использования цикла while и вместо этого использовать foreach, я мог бы с уверенностью выполнять этот рефакторинг; способ структурирования модульных тестов позволяет мне, на первый взгляд, увидеть и ожидать, что я честно хочу от этого кода.

Я не мог честно представить, что пытаюсь это сделать, если действительность была частью статического состояния. Это было бы жестким, чтобы снять.

Answer 2

В этом случае assertTrue - это static method, определенный в Assert.java.

Ваш источник обычно будет import static org.junit.Assert.*;, тем самым создавая все статические методы из класса Assert, доступного внутри источника тестирования. Вы также можете, как это сделано в руководстве JUnit Getting Started, статически импортировать только один метод, например метод assertEquals. Static imports были представлены в Java 1.5.

Языки OO-ish предоставляют способ записи методов, которые не работают на конкретном экземпляре объекта (например, Smalltalk или Scala).