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