Как юнит-тест бизнес-правил?

Question

Мне нужен юнит-тест, чтобы убедиться, что я правильно накапливаю время отпуска. Но часы отпуска накапливаются в соответствии с бизнес-правилом, и если правило меняется, то тестовый модуль прерывается.

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

Мой вопрос: как правильно изменить бизнес-правила модульного тестирования?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Таким образом, вы получаете четкое разделение проблем и сохраняете свои юнит-тесты ремонтопригодными. Вы также подчиняетесь Открытому / Закрытому Принципу.

Answer 4

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

Answer 5

Звучит правильно, что тест не пройден при изменении правил - этого и следовало ожидать.

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

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