Единичное тестирование - тот же метод, но для разных тестовых данных

Question

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

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

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

Repository вызов неудачен

1. с кодом ошибки
2. с Exception

Целевое назначение репозитория

1. возвращается нулевой результатом
2. возвращенных один результат
3. возвращенных более одного результата

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

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

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

Answer 1

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

// 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 (соглашение об именах, отстаиваемое тренером гибких/модульных тестов и автором Roy Osherove, среди прочих). Я могу посмотреть на имя и сразу узнать, что прошло или не получилось, не нужно задаваться вопросом, какая вариация могла пройти или провалилась. Это также помогает, что мой модульный тест не зависит от файловой системы.

Answer 3

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

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

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

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

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

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