Closed. This question is
opinion-based。它当前不接受答案。
想改善这个问题吗？更新问题，以便
editing this post用事实和引用来回答。
2年前关闭。
我是TDD和ATDD的新手，我想了解用户故事与其接受标准之间的联系。对于上下文，我正在C＃中构建一个具有MVC前端的3层应用程序。
举例来说，我有以下用户案例：
为了确保正确输入容量数据
作为一个人更新此数据
输入的数据不符合我们的业务规则时，我需要反馈。
对我而言，分解并定义“容量数据”是什么，以及管理此数据的业务规则对我来说很有意义。
例如，也许它的“机器数量”属性必须大于零。
我要避免做的是测试框架-如果我正确遵循的话，我想做的就是测试此业务逻辑是否正确实现，即：
在代码库中正确实现了业务规则（“机器数必须大于零”以及其他规则）。
如果违反业务规则，则会向用户发出此错误警报。
我相信我可以通过验证控制器中的无效模型状态重定向到同一页面来测试规则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);
}
当然，以上内容不会编译。为了简单起见，我暂未考虑任何特定的模拟或夹具框架。因此，为了使该测试至少可以编译（但仍然失败），我需要做出一些决定：
CapacityModel应该是一个视图模型吗？还是来自服务层的DTO？还是DAL层中的元数据类？我可以实现其中任何一个并通过测试...但是我真正应该测试什么？
“验证器”是否在检查验证此模型属性的服务的行为？还是CapacityModel上的数据注释？同样，我应该在3层应用程序的上下文中真正测试什么？
要考虑的一些事情：
我将知道的一件事是，数据库表将具有描述这些规则的约束-因此，看来该规则的目的实际上是将这些规则传达给正在使用该应用程序的任何人。在那种情况下，我可以安全地假设将规则显示在三个位置会违反DRY：视图模型，数据实体和数据库表。
我们在数据库中拥有这些规则的原因是，因为我们要确保DBA是否需要弄乱记录，以确保不会意外违反这些规则。但是，据我所知，没有一种很好的方法可以将这些CONSTRAINT规则转换为应用程序的DAL ...因此，我认为在应用程序中至少需要再重复一次这些时间，以便与它们进行通信。用户。
因此，如果我要编写一个满足业务规则的单元测试，那不是为了确保规则能够映射数据库而编写吗？另外，还编写单元测试以确保向用户显示正确的消息吗？
您可以提供的任何指导都是很棒的。我想感觉到我所做的决定是合理的，或者至少有一个更好地解决问题的替代方法的想法。
谢谢，
劳伦斯
编辑：
因此，最终，我试图以一种集中式的方式来管理应用程序中的验证，这样我就可以将关注点分离开来-即，控制器只关心路由，视图模型只关心显示数据，验证者只关心验证等...例如，与在视图模型中进行验证相反。
我发现一个非常有用的
article，可以帮助我使用现有的MVC基础结构来了解如何执行此操作。希望这将有助于其他人研究这类情况。