敏捷:模型的ATDD场景

本文关键字：ATDD 场景 模型 敏捷 | 更新日期: 2023-09-27 18:25:54

我是TDD和ATDD的新手，我想了解用户故事与其接受标准之间的联系。就上下文而言，我正在用C#构建一个具有MVC前端的三层应用程序。

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

为了确保正确输入容量数据作为更新此数据的人员当输入的数据不符合我们的业务规则时，我想要反馈。

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

例如，它可能有一个"Number of Machines"属性，该属性必须大于零。

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

  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层中的元数据类？我可以实现任何一个并使测试通过……但我真正应该测试什么
  2. "验证器"是否正在检查验证该模型属性的服务的行为？或者CapacityModel上的数据注释？同样，在三层应用程序的上下文中，我真正应该测试什么

需要考虑的一些事项：我知道的一件事是，数据库表将有描述这些规则的约束——所以这个规则的目的似乎真的是将这些规则传达给使用应用程序的人。在这种情况下，我是否可以放心地认为将规则显示在三个地方会违反DRY：视图模型、数据实体和数据库表。

我们在数据库中有这些规则的原因是，我们希望确保如果DBA需要篡改记录，这些规则不会被意外违反。然而，据我所知，没有一个很好的方法可以将这些CONSTRAINT规则转换为应用程序的DAL。。。所以我想，为了将它们传达给用户，它们需要在应用程序中至少再重复一次。

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

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

谢谢，

劳伦斯

编辑：

因此，最终我试图以一种集中的方式管理应用程序中的验证，这样我就可以将关注点分离开来——例如，控制器只关心路由，视图模型只关心显示数据，验证器只关心验证等……而不是在视图模型中进行验证。

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

敏捷:模型的ATDD场景

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

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

在你的例子中，我认为验收测试类似于：

对于简单的业务规则（机器数量必须大于零），确保在违反业务规则的情况下向用户提供正确的反馈。

在这个阶段，我会与产品负责人交谈，了解他们认为什么是"正确的反馈"，以及他们希望如何显示。

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

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

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

相关文章：