应用CQRS-您需要对薄读取层进行单元测试吗？鉴于一些实施CQRS的建议提倡相当接近于金属的查询实施，例如直接针对数据库的ADO.NET查询（或者可能是基于LINQ的ORM），尝试对它们进行单元测试是否错误？请问真的有必要吗？我对此事的看法：提供模拟“薄读取层”的额外架构复杂性似乎与将构建仪式保持在最低限度的建议的本质背道而驰。有效覆盖用户可能提出的查询的每个角度的单元测试量是惊人的。具体来说，我正在ASP.NETMVC应用程序中试验CQRS，并且想知道是要对我的控制器操作方法进行单元测试，还是只测试域模型。先感谢您。我倾向于同意你的观点，对这种代码进行单元测试并不是很有用。但仍有一些有用的测试空间。您必须对用户的读取查询参数进行一些验证，如果是这样，请测试无效的请求参数是否会引发合适的异常，并且是否允许有效参数。如果您使用的是ORM，我发现测试映射代码的成本/收益比太大了。假设您的ORM已经过测试，映射中可能存在错误，但您很快就会发现并修复它们。我还发现编写一些集成测试（使用相同的测试框架）很有用，只是为了确保我可以建立到数据库的连接并且ORM配置不会抛出任何映射异常。您当然不想编写查询实际数据库的单元测试。正如您可能已经知道的那样，单元测试与代码覆盖率和防止错误无关，它与良好的设计有关。虽然我经常在匆忙时跳过测试readmodel事件处理程序，但毫无疑问，可能完整的代码应该是TDD应该是的全部原因。我也没有对我的HTTP操作进行单元测试（因为我使用Nancy而不是.NETMVC，所以我没有控制器本身）。这些是集成点，不会包含太多逻辑，因为大部分逻辑都封装在命令处理程序和域模型中。我认为测试它们不容易的原因是因为它们非常简单且非常重复，几乎没有深入考虑读取模型的事件反规范化。我的HTTP处理程序也是如此，它几乎只处理请求并向域发出命令，并带有一些将响应返回给客户端的基本逻辑。在开发的时候，我经常会在这段代码中出错，如果我使用TDD，我可能会减少这些错误，但也需要更长的时间，而且这些错误往往很容易找到并修复。我的直觉告诉我，我仍然应该在这里应用TDD，它仍然是松耦合的，编写测试应该不难。如果您发现很难编写测试，则可能表明您的控制器中存在代码异味。根据我的经验，如果您要创建一个很好的非规范化读取模型，那么您将要执行的90%-99%的读取不需要围绕它们进行单元测试。我发现对于TDDCQRS应用程序最有效和有效的方法是编写将命令推送到域中的集成测试，然后使用查询从数据库中获取数据以用于断言。我看到像测试这个单元这样的事情的方式是让单元测试在数据库中创建一组东西，运行单元测试，然后清理创建的东西。在过去的一份工作中，我看到使用数据结构来描述对象及其关系的效果很好。这是通过ORM运行以创建这些对象，使用关系，使用来自该对象的数据进行查询，然后使用ORM删除对象。为了使单元测试更容易，为每个类设置指定的默认值，以便在不覆盖这些值的单元测试中使用。那么单元测试中的数据结构只需要指定非默认值，这使得单元测试的设置更加紧凑。这些单元测试非常有用，在数据库交互中发现了许多错误。在我的asp.netmvc应用程序中，我也应用了sqrc。但是我们使用文档数据库(mongodb)并且每个命令或事件处理程序直接更新数据库而不是sql和“ADO.NET查询”或“Linq”。我为命令/事件处理程序创建了一个测试。经过100%的单元测试后，我知道我的域在95%的时间内都可以正常工作。但是对于动作/控制器/我已经应用了ui测试（使用硒）。因此，似乎域的单元测试（命令/事件处理程序和对数据库的直接更新）和用户界面测试您的“集成测试”。我认为您至少应该测试域部分，因为所有逻辑都封装在命令/事件处理程序中。仅供参考：我也开始从实体框架开发域部分，而不是通过存储过程直接更新到数据库，但我对文档数据库非常满??意。我尝试了几种不同的文档数据库，但mongodb看起来最适合我。以上是C#学习教程：ApplyingCQRS-DoIneedtounittestthethinreadlayer?如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
