Это - плохая практика, чтобы иметь больше чем одно утверждение в модульном тесте? [закрытый]

«Модульный тест» должен тестировать 1 единицу, поэтому должен быть как можно меньше и проверять только 1 определенную вещь. Я бы посоветовал иметь только 1 утверждение

, НО я думаю, что это нормально иметь 2 утверждения, если они не расположены одно за другим.

Плохой пример

public void ValidateRulesEntry_Valid_ValidConditionsFromFile()
{
    string condition = "Target.HasValue";
    string returnMessage;

    bool successFul = CodeParserTryParseCondition(condition, out returnMessage);


    Assert.IsTrue(successFul);
    Assert.IsFalse(string.IsNullOrEmpty(returnMessage));
    Assert.IsTrue(returnMessage == "OK");

}

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

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

Ваши юнит-тесты должны быть достаточно мелкозернистыми. Как правило, чем меньше утверждений, тем больше вероятность, что ваш тест будет нацелен на конкретную функцию, а не будет смешивать тестирование для нескольких функций в одном тесте. Значит ли это, что все тесты должны иметь только одно утверждение? Нет, но я бы посчитал это «тестовым запахом», если бы нашел несколько утверждений, потенциально тестирующих несколько вещей в одном модульном тесте. Обрабатывайте этот «запах» так, как если бы вы чувствовали запах кода и рефакторинг теста, чтобы уточнить его, чтобы он проверял только одну «вещь» - даже если для этого требуется более одного утверждения.

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

var result = controller.Action() as ViewResult;

Assert.IsNotNull( result );
Assert.AreEqual( viewName, result.ViewName );

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

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

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

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

Подумайте:

assert(list.isEmpty());

FetchValues(list);

assert(list.count == expectedItemCount);

AssertValuesMatch(list,expectedValues);

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

Я не считаю это плохой практикой. Модульные тесты могут делать все, что хотят: утверждать, регистрировать в файлах, отправлять оскорбительные SMS-сообщения руководству, что угодно.

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

Вставьте все утверждения в том, что вы хотите. Серьезно.

Я стараюсь утверждать каждый шаг на пути к включению и включению конкретной цели моего теста.

Это не имеет значения. Единственное, что имеет значение, это то, что ваши юнит-тесты покроют все возможные ошибки.

Это пример «переосмысления».