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

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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