依赖注入，DDD 什么要单元测试（&mock）？ [关闭]答案

【问题标题】：Dependency Injection, DDD what to unit test (&mock)? [closed]依赖注入，DDD 什么要单元测试（&mock）？ [关闭]
【发布时间】：2023-03-17 19:56:01
【问题描述】：

我正在编写一些测试代码，用于测试带有 Castle Windsor DI、域驱动设计（应用程序/域服务、存储库、域模型）、NHibernate 和（很可能）MOQ 的 ASP.NET MVC Web 应用程序以进行模拟。可以测试的可能性是无穷无尽的，因为基本上所有东西都可以测试。

一些可能性例如：

有很多东西（这么多层 - 控制器、服务、存储库）似乎几乎不值得进行任何测试，因为它们通常非常简单。

对于较小的应用程序，目前尚不清楚什么可以带来最大的好处，但它会增长，并且相同的模式将用于更复杂的应用程序。

对于那些有类似应用程序的人，您在进行什么单元测试？

【问题讨论】：

你还没有说你的应用程序是做什么的......“类似的应用程序”太啰嗦了。有人可能在 2MLoc 应用程序上拥有相同的架构，但他们测试的内容将取决于他们对该应用程序所有功能的经验。如果您的 MVC 网页只有几页，我猜您实际测试的内容会大不相同。
应用程序本身非常简单，但它将成为一个非常广泛的应用程序的基础。使用报告等创建/编辑/更新/删除大量数据。至于类似的应用程序，我不知道在哪里划线。 MVC、DI、DDD 可能是主要因素，实际框架可能不那么重要。
我仍在努力回答您的问题。实际上，唯一正确的答案可能是对所有内容进行单元测试/模拟并获得 100% 的代码覆盖率。这意味着测试应用程序的所有内部工作。测试所有内部工作将允许您确保其他开发人员没有绕过您的架构。根据我使用中/大型应用程序的经验，这几乎是不可能的，当客户/利益相关者希望立即添加他们的功能时，100% 的代码覆盖率大多被排除在外！

【解决方案1】：

如果您没有足够的时间或刚开始编写测试，则域模型和应用程序服务是单元测试的第一公民。这些测试涵盖了最重要的部分（流控制的应用服务和业务规则的域模型）。当我开始学习编写测试时（当时不知道 TDD），它们是我唯一测试的部分。

那么在采用tdd之后一切都可以测试了。您将需要涵盖持久性、消息传递和其他集成点的集成测试（主要用于测试配置）。

【讨论】：

【解决方案2】：

“单元测试什么”问题的最佳答案是......一切 - 根据TDD :)

但是，确保正确配置的组件能够很好地协同工作是Integration Testing 或Smoke Testing 的一部分。

TDD 中的建议方案是与代码并行编写测试，因此两个代码同时增长。您的问题可能在于您已经拥有代码并且没有单元测试。这种情况有两种可能：

1) 您的组件分离良好。然后你可以为每个组件的公共接口编写单元测试，以达到高覆盖率（用一些覆盖率工具测量）。

2) 你的组件纠缠在一起。然后我建议尽可能多地编写集成测试，同时以高覆盖率为目标。这将比情况 1) 更难，因此最好测试最典型和关键的场景，然后重构代码以放松一些耦合，然后继续执行步骤 1)。

【讨论】：