Блог

Главная - Вопросы по программированию - Является ли использование Single в качестве Assert плохой практикой?

Является ли использование Single в качестве Assert плохой практикой?

#c# #linq #unit-testing

#c# #linq #модульное тестирование

Вопрос:

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

Я использую Single для тестирования этого поведения, которое работает нормально, поскольку оно не пройдет тест, вызвав исключение, если совпадений вообще нет или более одного совпадения. Но фактического утверждения нет, что каким-то образом нарушает rrange , ct, ssert . Поэтому мне интересно, является ли это плохой практикой и есть ли лучший способ сделать это.

Следующий псевдокод для демонстрации моего вопроса: 

 [TestMethod]
public void TestMethod()
{
    List list = MethodToTest(param1, param2);

    list.Single(s => s.Matches(condition));

    //No actual Assert
}

Комментарии:

1. Я думаю, что assert лучше, хотя бы потому, что вы можете предоставить более информативное сообщение о том, что и где не удалось.

2. Это вопрос, основанный на мнении… На мой взгляд, я бы не стал использовать Single для проверки того, что в UTs есть только 1 элемент… Я бы использовал Assert.Equal(1,list.Count(...))

3. @Jon, который все равно будет выбрасываться, когда будет более одного результата.

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

5. Вероятно, утверждение list.Count(s => s.Matches(condition)) == 1 было бы лучше.

Ответ №1:

Мне интересно, является ли это плохой практикой и есть ли лучший способ сделать это.

Да и да.

он не пройдет тест, выдав исключение, если совпадений вообще нет или более одного совпадения.

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

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

Комментарии:

1. Спасибо за ваш ответ. Вы правы, я не думал о разнице между неудачным тестом и тестом с ошибками.