Должна ли каждая возможная ветвь в методе иметь отдельный junit?

Question

Это больше вопрос дизайна.

Предположим, у вас есть такой метод (например):

if (x == 5) {
  c = 1;
} else {
 if (z != 2) {
  b = 6;
} else {
   a = 3;
}

Как вы думаете, лучше всего иметь джунит для каждой возможной ветви? То есть testx5, test xnot5znot2, testxnot5z2 и т. Д., Или что-то вроде:

void testMethod() {
// x is 5
test/assert code;

// x not 5, z not 2
test/assert code;

// x not 5, z is 2
test/assert code

// etc
}

РЕДАКТИРОВАТЬ: Просто чтобы быть ясно, моя цель - полное покрытие кода. Я просто хочу узнать мнение о том, должен ли я сделать новый тест для каждой ветви или объединить их в одном тесте. Спасибо за ваш вклад.

Answer 1

Часто задаваемые вопросы JUnit , кажется, указывают, что лучше иметь больше тестов с меньшим количеством утверждений, хотя бы потому, что JUnit будет сообщать только о первом сбое подтверждения в методе тестирования.С помощью одного метода, если вы разбили случай x = 5, у вас не было бы возможности узнать, работал ли какой-либо из случаев x! = 5.

Answer 2

То, что вы обсуждаете, называется Охват филиала .

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

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

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

Answer 3

В модульном тестировании ваша цель - протестировать поведение, а не «код».Подумайте о методе проверки черного ящика, и вы хотите убедиться, что он работает правильно.Вы не знаете, как это работает, но вы ожидаете определенных результатов для определенных входных данных.Таким образом, вы захотите создать тесты для разных случаев того, как вы ожидаете, что код будет работать, как если бы вы ничего не знали о том, как внутренняя часть метода на самом деле выполняет свою работу.Итак, вы бы написали тесты, такие как «applysDiscountToShoppingCart» и «addDeliveryFeeToShoppingCart».

Теперь, после всего сказанного, также полезно создать «крайние случаи», в которых вы тестируете вещи, которые могут сломатьсянапример, нулевые значения, нули, негативы, слишком большие / малые данные и т. д.), чтобы увидеть, не сработает ли это ожидаемым образом.Обычно для их написания необходимо знать, как на самом деле работает метод.Если вы можете разработать тесты, которые охватят весь ваш код, это здорово!100% тестирование - это определенная вещь, к которой нужно стремиться, но она не всегда практична (или полезна) в зависимости от ситуации.

Answer 4

Особенно на серверах сборки проще иметь много разных тестовых случаев / функций, потому что будет легко определить, какой тест не пройден.Другим недостатком является то, что тестовый набор будет остановлен, если первый не пройден, и вы не будете знать результат других тестовых случаев.

Лично для меня это преимущество прекращается, когда вам приходится многократно вставлять копии для установки.вверх / объяснить тестовый пример, в этом случае я просто сделаю несколько утверждений в одном тестовом примере.