我想问一下在 Web 开发中使用单元测试。单元测试的想法很棒，但它真的在 Web 应用程序的上下文中带来了价值吗？我的问题的第二部分是关于 TDD。如果在实际代码之前创建集成测试，这种方法可以称为“测试驱动开发”吗？
1. 假设
根据定义，单元测试应该只在一个服务层上测试代码。如果一个测试跨多个层测试代码，我们就有一个集成测试。
2. 论据
2.1 没有算法
Web 应用程序中的算法并不多。这不像构建一个 3D 物理引擎，其中每个方法都会做一些具有挑战性且难以调试的事情。Web 应用程序主要是关于集成和生成 HTML。
Web 应用程序的最大挑战是： - 干净的代码（任何软件的普遍问题，但不可测试） - 数据一致性 - 集成（编程语言、文件系统、配置文件、Web 服务器、缓存系统、数据库、搜索引擎、外部 API - 所有这些系统必须根据要求协同工作）
如果您想为 Web 应用程序中的每个类构建单元测试，您将测试（在大多数情况下）：填充数组、字符串连接和语言的本机函数。
2.2 成本
仅仅因为 Web 应用程序都是关于集成的，所以总是存在多个依赖项。你必须模拟许多不同的类，甚至编写一个小测试实际上可能是一项大工作。更糟糕的是，它不仅与测试有关。软件需要可测试。这意味着必须能够在几乎每个类中注入依赖项。在两个类（或系统）之间不创建额外层的情况下注入依赖项并不总是可能的。它使代码复杂化并使其使用起来更加昂贵。
3. 集成测试
如果 Web 开发都是关于集成的，为什么不测试它呢？很少有反驳的论点。
3.1 集成测试说“有些东西坏了”，但没有说在哪里
这真的归结为：与使代码“UnitTestable”和更复杂（我想这是主观的）所需的时间相比，集成测试失败需要多长时间才能找到错误？根据我的经验，找到问题的根源并不需要很长时间。
3.2 你可以在任何环境下运行单元测试，集成测试很难做到
是的，如果您想在没有数据库的情况下运行集成测试。通常有一个数据库。只要您在每次测试后对修复数据进行操作并进行清理，就应该没问题。事务数据库非常适合这项任务。打开事务，插入数据，测试，回滚。
3.3 集成测试难以维护
我无法对此发表评论，因为我所有的测试都运行良好，而且我从来没有遇到过问题。
4. 创建好的单元测试！
整个论点可以用“如果您正确地创建单元测试，那么您就没有任何问题。”来攻击。这不能与集成测试相同吗？如果创建集成测试更容易，为什么不坚持使用它并让它正确呢？
不要误会我的意思，我不反对单元测试。这是一个完美的主意，我向大家推荐。我试图理解：它真的适合 Web 开发吗？我想听听你的意见和经验。