Модульное тестирование - тот же метод, но для разных тестовых данных

Question

Это довольно простой вопрос о модульном тестировании.

У меня есть метод, например GetOrderDetails, который вызывает репозиторий для получения деталей заказа. У меня есть фиктивный репозиторий, который можно настроить так, чтобы он возвращал стоковые ответы.

Для тестирования метода GetOrderDetails я по крайней мере буду использовать следующие случаи -

Ошибка вызова репозитория

1. с кодом ошибки
2. с исключением

Успешный вызов репозитория

1. вернул ноль результата
2. вернул один результат
3. вернул более одного результата

Должен ли я писать один метод тестирования для тестирования вышеуказанных сценариев или это действительно отдельный метод тестирования для каждого из приведенных выше сценариев?

Я полагаю, если разбить его на несколько методов испытаний, это обеспечит как минимум следующие преимущества 1. более высокая изоляция в случае неудачных испытаний 2. количество кода в тестовом методе меньше 3. каждый метод тестирования будет нести ответственность за настройку одного репозитория, например либо настройка на отсутствие результата, либо настройка на несколько результатов и т. д.

Не могли бы вы помочь с вашими взглядами на это?

Answer 1

Я бы написал отдельный модульный тест для каждого случая. По сути, каждый раз, когда вы пишете if или switch внутри метода, который вы тестируете, это предполагает различные модульные тесты для обработки каждого случая. Причина этого заключается в том, что часть range вашего модульного теста будет отличаться в зависимости от того, какой маршрут вы хотите использовать в своем коде (разные ложные ожидания, настройки свойств и т. Д.). Также я бы порекомендовал вам организовать свой юнит-тест в следующих трех частях:

// arrange
// -> prepare mock objects, properties, setup expectations

// act
// -> invoke the method your are testing

// assert
// -> assert on the results returned by the method your are testing

Answer 2

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

Answer 3

Это действительно субъективный вопрос, и вы получите разные ответы.Несколько вещей, которые нужно иметь в виду.

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

2. Дублирование тестов модульного кода, только с одной переменной разницей - это кошмар обслуживания.Представьте, что у вас есть 5 модульных тестов, каждый из которых содержит 40 строк кода, и единственная разница между ними - глупое возвращаемое значение.Если вы сделаете это, вы будете чесать голову через 6 месяцев.

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

4. Самая сложная логика, которую я когда-либо использовал в модульном тесте, - это цикл for.И это только для инициализации простого массива, если он необходим для чего-то конкретного для теста.Я всегда держусь подальше от операторов if в модульных тестах.Но если вы используете тесты, управляемые данными, цикл for просто подходит для подачи данных в ваши тесты, если вам нужно это сделать.Но если цикл for невелик, разверните цикл тоже.

Я надеюсь, что некоторые из этих советов помогут.