如何在没有存储库模型的情况下在 ASP.Net MVC 上实现 TDD 和集成测试答案

【问题标题】：How to implement TDD and Integration Testing, without Repository model, on ASP.Net MVC如何在没有存储库模型的情况下在 ASP.Net MVC 上实现 TDD 和集成测试
【发布时间】：2016-09-03 07:20:05
【问题描述】：

我们小组刚刚开始研究 TDD 和单元测试。我们已经开始了存储库模型的道路，并且是可疑的。它似乎只测试一小部分代码，而需要大量的编码时间。我们还发现，大大增加的复杂性更难支持。再加上 SQL 或 UI 层中的大量业务逻辑没有被覆盖，并且需要更复杂的代码来覆盖该代码，......这似乎是在浪费时间。

不要误会我的意思，我想实现 TDD，但我想要一个从 UI 到 DB 进行测试的完整解决方案。是的，我知道这被称为集成测试，我真的不明白为什么有些人如此急切地指出 IT 与 UT 有很大不同，这是显而易见的。但是您为什么要选择 UT，带来如此多的复杂性，而您的努力却获得如此少的覆盖面。

您使用集成测试以哪些方式实施 TDD？

【问题讨论】：

用户 Blue Clouds 在其他地方有一个帖子，表明他在这方面取得了成功，我希望他能为这个线程做出贡献。
你可以看看 MVC (MVP) 架构，这使得 biz 逻辑代码在 UI 层中非常少见（并且只是微不足道的）。纯“模型”层往往更容易使用 UT 进行测试（尽管存储在 DB 中的过程以及与 DB 紧密耦合的代码可能更棘手，但在我的一个项目中，我在 DB 中有这样一部分功能，我宁愿在临时内存数据库上运行 UT，牺牲一些 UT 速度（从 ~1s 到 ~10s），以免在测试中模拟太多）。在那个特定的项目中，我什至根本没有使用 UI 层测试，因为 UI 只是模型之上的微不足道的薄层，而是 YMMV。

标签： unit-testing tdd integration

【解决方案1】：

TDD 通常会因为复杂性增加和难以维护而受到指责，但根据我的经验，这不仅仅是 TDD 的结果。 TDD 促进松散耦合，这通常会导致更多的类但更简洁的类，如果你来自一种编码风格，你倾向于拥有更大的类和隐藏的依赖项，那么乍一看，TDD 确实看起来增加了复杂性。但实际上它揭示了所有存在但很可能隐藏的依赖关系。

使用 TDD，您应该编写更少的代码，因为您只编写了足够的代码来使您的单元测试通过，但是您的代码往往被分成更小的块。在我目前的项目中，我们练习 TDD 并进行了大量单元测试，显然这些是首先编写的，我们还进行了集成测试以确保各层可以很好地协同工作，但集成测试只是测试我们已经知道的部分的总和（在大多数情况下）正在工作。我们还有一个使用 selenium 构建的 UI 测试套件。

最后一点是，在进行 TDD 时，您可能会在抽象事物方面走得太远，我总是使用 3 规则来保持我的内联 https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

【讨论】：

【解决方案2】：

但是你为什么会选择 UT，带来如此多的复杂性，而且变得如此很少有报道换来你的努力？

一旦您注入了依赖项，UT 的实施成本就不会太高。当针对具有大量逻辑（开关、大量 if 等）的某个类时，我会选择 UT。

您将希望使用 IT 来断言来自某个家庭的场景正在端到端工作（例如，单击注册按钮、创建用户、针对数据库进行断言）。您不会使用 IT 来涵盖代码中的所有场景和 if，因为它比 UT 更昂贵（这也意味着慢）。

话虽如此，您可能希望将 UI/DB 中的逻辑更多地移至后端（尽管肯定有用于隔离和测试 UI 的工具） - 您的解决方案可能更易于管理，因此也更容易规模化（如果有可能的话）。

【讨论】：

感谢您的回复！