如何对业务规则进行单元测试？

Question

我需要进行单元测试，以确保我正在积累假期。但是假期时间根据业务规则累积，如果规则发生变化，则单元测试会中断。

这可以接受吗？我应该通过一个方法公开规则，然后从我的代码和我的测试中调用该方法，以确保单元测试不是那么脆弱吗？

我的问题是：对可能发生变化的业务规则进行单元测试的正确方法是什么？

Answer 1

您的测试应确保代码正确遵守业务规则。因此，我不会编写围绕业务规则的测试或依赖业务规则代码本身。相反，当业务规则发生变化时，我会先更改测试以反映新的业务规则，然后当我的代码不再通过测试时，去修复代码以便通过测试。

您不希望发生的是编写测试，以便在更改应用相同业务规则的方式时，您的测试会中断。说起来容易做起来难，但基本上你要测试的是实现规则所需的最低要求，而不是过于狭隘地规定代码的实现方式。但是，如果规则的结果不同，那么您应首先更改测试，然后再更改代码以匹配它。

您也不希望测试与特定数据耦合。比如在进行税收计算时，不应写下您的测试，以假设被测试的类使用5％作为税。相反，您应该编写测试以便提供税率，然后检查计算是否正确完成。据推测，您将需要测试一系列值，以确保捕获超出范围的值。这样做的一个结果是，您将拥有更好的设计，因为这将帮助您避免硬编码值，并使您的生产代码更灵活地适应数据的变化。

Answer 2

我有类似的设置 - 但我的业务规则已编译但具有可配置选项（您的可能不同）。当业务规则改变其运行的核心方式时，我的单元测试会中断。这实际上是预期的 - 而且好！这意味着我可以隔离整个系统中的任何意外涟漪并更新测试以匹配更改。

如果您的规则是外部的（某种脚本语言或数据库sproc），那么您需要将它们包装在集成测试中，并连接集成测试以实现自动执行。虽然不再是单元测试，但集成测试也非常重要，它将以与单元测试相同的方式帮助您，以防止由于业务规则更改而出现意外涟漪。

Answer 3

听起来您有业务规则，然后您拥有这些业务规则的客户。如果这两者可以独立变化，那么相应地设计API是明智的。

如上所述，您的问题听起来可以通过适当使用策略模式来解决。该策略代表了您的业务规则，因此您可以在纯上下文中对这些规则进行单元测试，而无需担心客户端。

当业务规则发生变化时，简单地将旧策略保留原样（以后再次需要它）可能更有意义，并编写（和单元测试）一个代表新业务规则的全新策略

完成新策略后，您可以在客户端中替换策略。

在对客户进行单元测试时，您应该针对测试双重策略（如模拟或存根）进行测试，以验证客户端是否与策略正确交互，而不依赖于任何特定的策略实施。

通过这种方式，您可以清楚地分离关注点并保持单元测试的可维护性。你也遵守开放/封闭原则。

Answer 4

如果规则发生变化，测试失败，这听起来是正确的 - 这是可以预期的。

如果您在测试中使用数据夹具而不是硬编码值，则可以在将来更轻松地维护测试。例如，如果你的方法应该返回foo，你可以在夹具中使用它。当您更改业务逻辑时，您只需更改夹具，您就不必进行单元测试。

当然，这在很大程度上取决于您正在测试的逻辑类型，并且可能并不总是适用。

Answer 5

我认为这是一个不正确的问题 业务规则和单元测试处于不同的抽象级别。 业务规则处于顶层抽象（业务建模），但单元测试用于测试最低抽象级别的代码单元，因此 您不能使用单元测试来验证或验证业务排除。 此外，分析和设计之后的业务规则可能会影响多个代码单元，因此再次使用单元测试来验证或验证业务规则。 我认为您可以使用测试用例或BDD方案来验证和验证业务规则。