应用CQRS - 是否需要对瘦读层进行单元测试？

Question

鉴于实施CQRS的一些建议主张相当接近金属查询的实现，比如ADO.NET直接针对数据库（或者基于LINQ的ORM）进行查询，尝试和单元测试他们？

我想知道它是否真的有必要？

我对此事的看法：

1. 附加架构复杂性提供了mockable“薄再现层”似乎相反意见的本质，以建筑仪式降到最低。
2. 有效覆盖用户可能撰写的每个查询角度的单元测试数量都很可怕。

具体而言，我试图CQRS出在ASP.NET MVC应用程序，并想知道是否打扰单元测试我的控制器操作方法，或者只是测试域模型。

非常感谢提前。

Answer 1

我倾向于同意你，单元测试这种代码不是那么有益。但是一些有用的测试仍然有一定的空间。

您必须执行一些验证用户的读取查询参数，如果是这样，则测试无效的请求参数抛出合适的异常，并有效参数是允许的。

如果您使用的是ORM，我觉得成本/效益比太大，测试映射代码。假设您的ORM已经过测试，映射中可能存在错误，但您很快就会发现并修复它们。

我也觉得它有用编写一些集成测试（使用相同的测试框架），只是要确定我可以对数据库的连接，和ORM配置不抛出任何异常的映射。你当然不想编写查询实际数据库的单元测试。

Answer 2

我看过像这个单元测试过的东西的方式是让单元测试在数据库中创建一组东西，然后运行你的单元测试，然后清理创建的东西。

在过去的一个工作中，我看到使用数据结构很好地设置了对象及其关系。这是通过ORM运行来创建这些对象的，这些关系中的数据用于查询，然后使用ORM删除对象。为了使单元测试更容易设置每个类指定的默认值，以在未覆盖这些值的单元测试中使用。然后单元测试中的数据结构只需要指定非默认值，这就使得单元测试的设置更为紧凑。

这些单元测试非常有用，并且在数据库交互中遇到了一些错误。

Answer 3

在我的一个asp.net mvc应用程序中，我也应用了sqrc。但是，我们使用document database(mongodb)和每个命令或事件处理程序直接更新数据库，而不是sql和'ADO.NET查询'或'Linq'。

而且我为一个命令/事件处理函数创建了一个测试。经过100％的单元测试，我知道我的域名在95％的情况下正常工作。 但是对于actions/controllers/ui我已经应用了ui测试（使用selenium）。

因此，似乎这两个域（命令/事件处理程序和直接更新数据库）的单元测试和ui测试它的'集成测试'。

我认为你至少应该测试域部分，因为你的所有逻辑封装在命令/事件处理程序中。参考文献：

仅供参考：我也开始从实体框架开始开发域部分，而不是通过存储过程直接更新到数据库中，但对文档数据库非常满​​意。我尝试了一些不同的文档数据库，但mongodb看起来对我来说最好。

Answer 4

正如你可能已经知道的单元测试较少关于代码覆盖率和防止错误，而不是关于良好的设计。尽管当我匆忙时，我经常跳过对读取模型事件处理程序的测试，但毫无疑问，可能应该为代码应当TDD的所有原因完成此工作。

我还没有进行单元测试我的HTTP操作（因为我使用的南希不.NET MVC我没有控制器本身）。

这些集成点和不倾向于包含很多逻辑，因为大部分被封装在命令处理程序和领域模型。

之所以我觉得这很容易不去测试这些，是因为它们非常简单而且非常重复，在读取模型中对事件的非规范化几乎没有深入的思考。我的HTTP处理程序也是如此，它几乎只是处理请求并向域发出命令，并有一些基本逻辑用于向客户端返回响应。

在开发时，我经常在代码中犯错误，如果我使用TDD，我可能会犯这些错误的次数要少得多，但这也需要更长的时间，这些错误往往很容易被发现和修复。

我的直觉告诉我，我应该仍然适用TDD这里虽然，它仍然是一切都非常松耦合的，它不应该是很难写的测试。如果您发现很难编写可能表明控制器中存在代码异味的测试。

Answer 5

根据我的经验，如果你正在创建一个很好的非规范化阅读模型，你将会做90％-99％的阅读不要保证有他们周围的单元测试。

我发现TDD CQRS应用程序最有效和最高效的方法是编写集成测试，将命令推送到您的域中，然后使用查询从数据库中为您的断言取回数据。