Как к бизнес-правилам модульного теста?
Проверка на наличие нескольких зависимостей и информирование конечных пользователей о состоянии
for cmd in latex pandoc; do
printf '%-10s' "$cmd"
if hash "$cmd" 2>/dev/null; then
echo OK
else
echo missing
fi
done
Пример вывода:
latex OK
pandoc missing
Настройте 10 на максимальную длину команды , Не автоматический, потому что я не вижу не многословного способа POSIX сделать это: Как выровнять столбцы разделенной пробелами таблицы в Bash?
4 ответа
Ваши тесты должны гарантировать, что код должным образом подчиняется бизнес-правилу. Поэтому я бы не стал писать тесты, которые обходят бизнес-правила или полагаются на сам код бизнес-правил. Скорее, когда бизнес-правило изменяется, я бы сначала изменил тест, чтобы отразить новое бизнес-правило, а затем, когда мой код больше не проходит тест, исправлю его, чтобы он прошел тест.
Что вы не делаете? Я не хочу, чтобы ваш тест был написан таким образом, чтобы при изменении способа применения того же бизнес-правила ваш тест ломался. Это легче сказать, чем сделать, но по сути то, что вы хотите протестировать, - это минимум, необходимый для реализации правила, не ограничивая слишком узко, как реализуется код. Если же результат действия правила отличается, то сначала следует изменить тест, а затем соответствующий ему код.
Вы также не хотите, чтобы тест был связан с конкретными данными. Скажем, при расчете налога ваш тест не должен быть написан так, чтобы предполагать, что тестируемый класс использует 5% в качестве налога. Вместо этого вам следует написать свой тест так, чтобы он предоставлял процент налога, а затем проверял правильность расчета. Предположительно, у вас будет диапазон значений для тестирования, чтобы убедиться, что значения, выходящие за пределы диапазона, также обнаруживаются. Одним из результатов этого является то, что у вас будет лучший дизайн, поскольку это поможет вам избежать жестко запрограммированных значений и сделает ваш производственный код более гибким для изменения данных.
вы должны написать свой тест, чтобы он указывал процент налога, а затем проверял правильность расчета. Предположительно, у вас будет диапазон значений для тестирования, чтобы убедиться, что значения, выходящие за пределы диапазона, также обнаруживаются. Одним из результатов этого является то, что у вас будет лучший дизайн, поскольку это поможет вам избежать жестко запрограммированных значений и сделает ваш производственный код более гибким для изменения данных. вы должны написать свой тест, чтобы он указывал процент налога, а затем проверял правильность расчета. Предположительно, у вас будет диапазон значений для тестирования, чтобы убедиться, что значения, выходящие за пределы диапазона, также обнаруживаются. Одним из результатов этого является то, что у вас будет лучший дизайн, поскольку это поможет вам избежать жестко запрограммированных значений и сделает ваш производственный код более гибким для изменения данных.It sounds like you have business rules, and then you have clients of those business rules. If those two can vary independently, it would be wise to design your API accordingly.
As presented, your question sounds like it can be solved with appropriate use of the Strategy pattern. The Strategy represents your business rules, so you can unit test those in a pure context without worrying about the client.
When the business rule changes, it may make more sense to simply leave the old Strategy as is (in case you need it again later on), and write (and unit test) a completely new Strategy that represents the new business rule.
When you are completely done with the new Strategy, you can replace the Strategy in the client.
When unit testing the client, you should do that against a Test Double Strategy (like a Mock or Stub) to verify that the client interacts correctly with the Strategy without being dependent on any particular Strategy implementation.
In this way, you get clean separation of concerns and you keep your unit tests maintainable. You also obey the Open/Closed Principle.
У меня аналогичная настройка, однако мои бизнес-правила скомпилированы, но имеют настраиваемые параметры (ваши могут отличаться). Когда бизнес-правило меняет основной способ работы, мои модульные тесты ломаются. Это действительно ожидаемо - и хорошо! Это означает, что я могу изолировать любые неожиданные колебания в моей системе и обновить тесты, чтобы они соответствовали изменениям.
Если ваши правила внешние (какой-то язык сценариев или sproc базы данных), вам нужно будет заключить их в интеграционный тест и подключите свои интеграционные тесты для автоматического выполнения. Хотя интеграционные тесты больше не являются модульными тестами, они также довольно важны и помогут вам точно так же, как модульные тесты, в предотвращении непредвиденных колебаний из-за изменения бизнес-правил.
Кажется правильным, что тест не проходит, если правила изменяются - этого и следовало ожидать.
Вы можете упростить поддержку теста в будущем, если вы используете фиксацию данных вместо жестко закодированных значений в тесте сам. Например, если ваш метод должен возвращать foo, вы можете получить это в fixture. Когда вы меняете бизнес-логику, вы просто меняете приспособление, и вам не нужно будет проходить сам модульный тест.
Конечно, это сильно зависит от типа логики, которую вы тестируете, и не всегда может быть применимо.