Разве плохо использовать управляющие операторы в вспомогательных библиотеках, которые помогают при тестировании?

Question

Я нахожу, что не могу использовать контрольные операторы в модульных тестах, очень утомительно и ограничивающе, и я пытаюсь понять, где находятся границы, и если я неправильно понимаю руководство. Я понимаю, что считается плохим иметь какую-либо логику управления (зацикливание, переключение) и т. Д. Непосредственно в тестовом коде. Разве плохо иметь управляющую логику в библиотеках, которая выделяет общую логику в тестовом коде (для использования исключительно тестовым кодом)? Например, если у меня есть метод, который создает объект, и у этого объекта есть несколько экземпляров компонентов (например, у заказа есть несколько продуктов), я не должен принимать переменную, которая указывает, сколько компонентов должен создать вспомогательный код для этого объекта. (потому что взятие переменной будет применять цикл для построения графа объекта)? И если это действительно плохая практика для модульных тестов, приемлемо ли это для другого класса тестирования?

Answer 1

Контроль потока в тестах

Я всегда находил что-то кроме самой базовой логики в тестах плохой идеей. Тесты должны быть как можно более декларативными. Если вы указываете, каков результат, а не как его достичь, у него есть несколько преимуществ:

Во-первых, тестовый код обычно намного проще (примечание: «проще» здесь не всегда означает «терзатель», это просто означает, что намерение проще вывести и выполнить.)

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

Библиотеки тестирования

Если у вас есть общие вспомогательные типы тестов в библиотеке, на которую вы полагаетесь, вполне логично, если у них есть логика , пока вы их тестируете! Пример: до добавления данных в NUnit 2.5 до тестируя, мы создали нашу собственную функциональность тестирования на основе данных и использовали ее довольно часто. Код, управляемый данными, сам по себе имел тесты для проверки его правильного функционирования. На мой взгляд, все, что вы используете для проверки правильности, должно быть изучено даже больше, чем обычно. Вы бы не хотели строить на чем-то, что дает ошибочные результаты, не так ли? :)

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