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

Question

鉴于实现CQRS的一些建议提倡相当接近金属的查询实现,例如直接针对数据库(或者可能是基于LINQ的ORM)的ADO.NET查询,尝试单元测试是错误的他们？

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

我对此事的看法:

1. 提供可模拟的"薄读取层"的额外架构复杂性似乎与将建筑仪式保持在最低限度的建议的本质相反.
2. 有效覆盖用户可能构成的每个查询角度的单元测试数量是可怕的.

具体来说,我正在ASP.NET MVC应用程序中尝试CQRS,并且想知道是否打扰单元测试我的控制器操作方法,或者只是测试域模型.

提前谢谢了.

Answer 1

根据我的经验，如果您正在创建一个很好的非规范化读取模型，那么您将执行 90%-99% 的读取操作不保证对它们进行单元测试。

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

Answer 2

我倾向于同意您的观点，即对此类代码进行单元测试并不是那么有益。但是仍然有一些有用的测试空间。

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

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

我还发现编写一些集成测试（使用相同的测试框架）很有用，只是为了确保我可以连接到数据库，并且 ORM 配置不会引发任何映射异常。您当然不想编写查询实际数据库的单元测试。