Должен ли я проверить, что методы не генерируют исключения?

Question

Я делаю свои первые шаги ребенка с модульным тестированием и написал (среди прочего) эти два метода:

    [TestCase]
    public void InsertionSortedSet_AddValues_NoException()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);
    }

    [TestCase]
    public void InsertionSortedSet_AddValues_CorrectCount()
    {
        var test = new InsertionSortedSet<int>();

        test.Add(5);
        test.Add(2);
        test.Add(7);
        test.Add(4);
        test.Add(9);

        Assert.IsTrue(test.Count == 5);
    }

Действительно ли нужен NoException метод?Если будет сгенерировано исключение, оно будет сгенерировано и в методе CorrectCount.

Я склоняюсь к тому, чтобы сохранить его как 2 тестовых случая (возможно, рефакторинг повторного кода как другого метода), потому чтоТест должен проверять только одну вещь, но, возможно, моя интерпретация неверна.

Answer 1

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

---

Есть два простых вопроса, которые обычно помогают мне определитьподозрительный тест и выяснение, имеет ли смысл тест:

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

Обратите внимание, что чрезвычайно легко иметь дело с этими вопросами, имея в виду второй тест (_CorrectCount).На самом деле мы не видели Add код метода, но мы, скорее всего, можем дать достойную догадку, что можно изменить, чтобы нарушить этот тест.Проверенная функциональность еще более очевидна.Ответы интуитивно понятны и выглядят быстро (что хорошо!).

Теперь давайте попробуем ответить на эти вопросы для первого теста (_NoException).Это сразу поднимает новые вопросы ( Является ли рабочий код реальной функциональностью? Разве это не очевидно? Разве это не подразумевается? Разве это не то, к чему мы всегда стремимся? Почему нет конца в конце? Как я могузаставить его потерпеть неудачу? ).Что касается второго вопроса, то это еще хуже - для того, чтобы пройти этот тест, вероятно, потребовалось бы явное выбрасывание исключения ... с которым мы все согласны, это не тот путь.

Вывод

Прост.Второй тест - прекрасный пример хорошо написанного блока теста .Это коротко, оно проверяет одну вещь, это легко понять.Первый тест не является .Даже несмотря на то, что он такой же короткий и (что кажется) простым, он вводит новые вопросы (хотя он действительно должен отвечать на уже поставленные вопросы - Действительно ли Add добавляет? Да. ) - и какрезультат приносит ненужную сложность.

Answer 2

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

Answer 3

Я всегда проверяю как рабочие, так и нерабочие случаи. Таким образом, вы проверяете, что код работает, возвращает правильные результаты, а также обрабатывает ошибки ожидаемым образом.

Answer 4

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

IMO, один тест должен проверять некорректное поведение (ожидая появления ошибки), а другой -правильное поведение (без исключения, возвращено правильное значение).

Answer 5

Здесь нет 100% правильного ответа.

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

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

Answer 6

Имо, если вы уверены, что список InsertionSortedSet работает (я не уверен, откуда он взялся), я бы пропустил тестирование InsertionSortedSet_AddValues_NoException, как вы собираетесь делать, если это необходимо.

Конечно, лучше тестировать как можно больше.