Web 开发中的单元测试与集成测试 [已关闭]
我想问一下在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开发吗？我想听听你的意见和经验。
