Как вы пишете тесты для кода, который требует дублирования тестируемого кода?

Question

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

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

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

Answer 1

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

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

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

Answer 2

Ручной расчет и жесткое кодирование плохи в рабочем коде, но необходимы для хороших модульных тестов.

Как правило, вы хотите написать один тест для каждого «состояния» кода. Например, я часто пишу тесты с положительным, отрицательным и нулевым входами, чтобы убедиться, что код работает должным образом.

Answer 3

Как правило, я делаю магическое число, которое самодокументируется, но жестко закодировано, как

const int Ожидаемый результат = 2 * 4 / someConstant; // возможно комментарий.

Читатель теста может определить, какие значения, или вы можете добавить дополнительные комментарии, если необходимо.

Answer 4

«Юнит-тест» на самом деле должен просто тестировать один юнит. Поэтому в идеале у вас должны быть отдельные юнит-тесты для вашего GeometryGenerator, еще один для вашего PathGeometry класса, третий для вашего ArcSegment и т. Д.

Путем отдельного тестирования каждого из модулей вы можете получить некоторую уверенность в том, как они будут себя вести, когда вы вызываете для них определенные операции с заданным набором входов (как ведет себя GeometryGenerator, когда поле в ArcSegment установлен в 1, по сравнению с тем, как он ведет себя, когда то же поле установлено в 0, и т. д.).

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