Когда можно сменить «завершенные» модульные тесты?

Question

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

Когда допустимо изменять ранее работающие юнит-тесты?

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

Answer 1

Для «правильного» TDD сначала измените тест, , затем измените код.

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

Answer 2

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

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

Answer 3

Когда вы вносите изменения, которые нарушают тесты:

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

2). Если это первое, исправьте тест. Еще исправьте ваши изменения.

Answer 4

Каждый раз, когда вам нужно.

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

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

Answer 5

Когда изменяются требования. Независимо от того, изменили ли вы свой код, а затем посмотрите, какие тесты прерываются по какой причине (как предложил Митч), или измените ваши тесты, а затем измените код (как на это ссылается Visage), тесты будут меняться только в том случае, если функциональность равна предполагается сделать что-то другое.

Answer 6

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

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

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

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

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