2016-05-16 3 views
0

Я несколько новичок в TDD и JUnit, я знаю, что могу написать тестовые примеры для методов, которые я реализую в своем коде.Есть ли способ отслеживать каждое утверждение тестового примера с несколькими утверждениями в JUnit?

И, очевидно, в моем коде есть методы, которым необходимо проверить несколько угловых случаев, чтобы проверить, что реализация метода в порядке. Поскольку, как правило, хорошая практика заключается в том, что один метод тестирования поддерживается одним методом в коде, я должен добавить несколько утверждений для такого метода, как описано в этом ответе. https://stackoverflow.com/a/762582/5715934

public void testValueOf() { 
    assertEquals(1, Integer.valueOf("1").intValue()); 
    assertEquals(0, Integer.valueOf("0").intValue()); 
    assertEquals(-1, Integer.valueOf("-1").intValue()); 
    assertEquals(Integer.MAX_VALUE, Integer.valueOf("2147483647").intValue()); 
    assertEquals(Integer.MIN_VALUE, Integer.valueOf("-2147483648").intValue()); 
.... 
} 

Но когда я выполнения тестового примера, я не получаю состояние теста (годен/не годен) для каждого утверждения внутри метода испытаний. Вместо этого он показывает «красный», даже если одно утверждение не работает и зеленое, если все переданы.

Не проще ли отслеживать каждое утверждение, чтобы облегчить отладку? И есть ли формальный способ/инструмент/обходной путь для этого (JUnit 4)?

+1

Это * Плохая Практика *, чтобы иметь один тест на один метод. У вас должен быть отдельный тест для разных тестовых случаев. –

+0

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

+0

@krzyk прав. Отделите все свои тестовые примеры, чтобы вы могли узнать, с кем не удается и по какой причине. Это значительно облегчает объяснение причин неудачи ваших тестов. Они также должны быть независимы друг от друга, чтобы гарантировать, что ни один тестовый пример не может привести к сбою другого. – Dale

ответ

1

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

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

Единственный способ узнать, какое утверждение не удалось, это посмотреть на трассировку сообщения/стека. Но, как правило, если тест не удается, вы знаете, что что-то не так, вы открываете IDE и смотрите на тест.

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