敏捷:模型的ATDD场景

Question

我是TDD和ATDD的新手，我想了解用户故事和它的接受标准之间的联系。对于上下文，我正在用C#构建一个3层应用程序，并使用MVC前端。

例如，假设我有以下用户故事：

为了确保容量数据被正确地输入，作为一个用户更新这个数据，当输入的数据不符合我们的业务规则时，需要反馈。

对我来说，将其分解并定义什么是“容量数据”以及管理此数据的业务规则是有意义的。

例如，它可能有一个必须大于零的“机器数量”属性。

我想避免做的是测试框架--如果我正确地遵循，我要做的是测试这个业务逻辑是否正确实现，即：

1. 在代码库中正确地实现了业务规则(“机器数量必须大于零”等)。
2. 如果违反了业务规则，则会提醒用户注意此错误。

我相信我可以通过验证控制器重定向到同一个页面中的无效模型状态来测试规则#2 --这方面有很多例子。

但是，这样做不需要在视图模型上添加装饰--这最终是从用户的角度实现业务规则吗？(从而满足#1?)

假设我有以下类型的语句/单元测试：

[Test]
public void GivenCapacityModelWhenNumMachinesZeroOrLessThenModelShouldBeInvalid()
{
   // Given
   IValidatorThing validator = new ValidatorThing(); //What enforces the rule? Should this be a controller service? Or a decorator such as [Range(0.000001,1000000)]? Doesn't each require different testing methods?
   var invalidModel = new CapacityModel(); // Or the viewmodel?
   double zeroValue = 0.000001;
   invalidModel.NumMachines = zeroValue;

   // When
   var modelIsValid = ValidatorThing.validateModel(invalidModel); 

   // Then
   Assert.IsFalse(modelIsValid);
}

当然，上面的内容不会编译。为了保持简单，我暂时忽略了任何特定的模拟或固定框架。因此，为了使这个测试至少编译(但仍然失败)，我有一些决定要做：

1. CapacityModel应该是一个视图模型吗？还是服务层的DTO？还是DAL层中的元数据类？我可以实现任何一个，并使测试pass...but，我真正应该测试什么？
2. “验证器”是否检查验证此模型属性的服务的行为？还是CapacityModel上的数据注释？同样，在3层应用程序的上下文中，我到底应该测试什么？

需要考虑的是:有一件事我会知道，数据库表将有描述这些规则的约束--所以这条规则的目的似乎是真正地将这些规则传达给那些使用应用程序的人。在这种情况下，我是否可以安全地假设将规则显示在三个位置:视图模型、数据实体和数据库表将违反DRY。

之所以在数据库中有这些规则，是因为我们希望确保DBA需要处理记录，以确保规则不会被意外违反。然而，据我所知，没有一种很好的方法可以将这些约束规则转换为application...so的DAL，我认为为了将它们传递给用户，它们至少需要在应用程序中重复一次。

所以，如果我要编写一个单元测试来满足业务规则，难道我写这些规则不是只是为了确保规则反映数据库吗？另外，还编写了确保向用户显示正确消息的单元测试吗？

任何你能提供的指导都会很棒。我想要感觉我所做的决定是合理的，或者至少有一个更好地解决问题的替代方法的想法。

谢谢,

劳伦斯

编辑：

所以，最终，我试图以一种集中的方式来管理应用程序中的验证，这样我就可以将关注点分离--也就是说，控制器只关心路由，视图模型只关心显示数据，验证器只关心验证，例如，etc...as反对在视图模型中进行验证。

我发现了一个非常有用的文章，它帮助我掌握了如何使用现有的MVC基础设施来实现这一点。希望这将有助于其他研究这类场景的人。

Answer 1

我怀疑您可能混淆了单元测试和验收测试之间的界限。

验收测试是非常以业务用户为中心的。它将应用程序视为黑匣子，但检查以确认应用程序的接口是否以用户期望的方式运行。

在您的示例中，我会看到验收测试是这样的：

对于简单的业务规则(机器数量必须大于零)，请确保在违反业务规则时向用户提供正确的反馈。

在这个阶段，我会和产品负责人聊天，了解他们认为什么是‘正确的反馈’，以及他们希望如何显示它。

重要的是，您没有测试如何评估业务规则，也没有测试用于处理错误的内部机制。您完全专注于最终用户的交互。

当然，您还需要实现单元测试，以确保您的技术解决方案是可靠的，这就是您了解业务逻辑实现位置的详细信息。

如何处理业务逻辑在很大程度上是一个设计决策。就我个人而言，如果我在数据库中有业务逻辑，我还会有一个包含规则描述的表，该表将在规则被违反时用作查找。应用程序的其他层对业务逻辑一无所知，但知道如何传递错误消息。