Java Web开发中的单元测试与集成测试

我想问一下在Web开发中使用单元测试的问题。单元测试的想法很好，但它真的在web应用程序的上下文中带来了价值吗？我问题的第二部分是关于TDD的。如果在实际代码之前创建集成测试，这种方法可以称为“测试驱动开发”吗

1。假设

根据定义，单元测试应该只在一个服务层上测试代码。如果一个测试跨多个层测试代码，我们就有一个集成测试

2。论点

2.1无算法

Web应用程序中的算法并不多。这不像构建一个3D物理引擎，每个方法都会做一些具有挑战性且难以调试的事情。Web应用程序主要是关于集成和生成HTML的

web应用程序面临的最大挑战是： -干净的代码（任何软件的通用问题，但不可测试） -数据一致性 -集成（编程语言、文件系统、配置文件、Web服务器、缓存系统、数据库、搜索引擎、外部API—所有这些系统都必须根据请求协同工作）

如果您想为web应用程序中的每个类构建单元测试，您将要测试（在大多数情况下）：填充数组、字符串连接和语言的本机函数

2.2成本

正因为Web应用程序都是关于集成的，所以总是存在多个依赖项。你必须模仿许多不同的类，编写一个小测试实际上可能是一项艰巨的任务。更糟糕的是，不仅仅是考试。软件需要是可测试的。这意味着必须能够在几乎每个类中注入依赖项。如果不在两个类（或系统）之间创建附加层，则不可能总是注入依赖项。它使代码复杂化，使用成本更高

3。集成测试

如果web开发都是关于集成的，为什么不测试它呢？几乎没有相反的论点

3.1集成测试说“有些东西坏了”，但没有说在哪里

这实际上可以归结为：当集成测试失败时，与使代码“可单元测试”和更复杂（我想这是主观的）所需的时间相比，发现bug需要多少时间？根据我的经验，找到问题的根源从来不会花很长时间

3.2您可以在任何环境下运行单元测试，集成测试很难实现

是，如果您想在没有数据库的情况下运行集成测试。通常有一个数据库。只要您对修复数据进行操作并在每次测试后进行清理，就应该可以了。事务数据库非常适合此任务。打开事务、插入数据、测试、回滚

3.3集成测试很难维护

我不能对此发表评论，因为我所有的测试都很好，我从来没有遇到过这个问题

4。创建好的单元测试

可以用“如果您正确创建了单元测试，那么您就没有任何问题”来攻击整个论点。集成测试就不能这样吗？如果创建一个集成测试更容易，为什么不坚持它并使它正确呢

---

别误会，我不反对单元测试。这是个好主意，我向大家推荐。我试图理解：它真的适合web开发吗？我想听听你的意见和经验

简短的回答是肯定的。单元测试和集成测试一样有价值。 就我个人而言，我并不擅长做TDD，但我注意到它极大地改进了设计，因为我必须先思考，然后编写代码。 这是无价的，至少对我来说，但它也需要很多时间去适应。 我认为，这是它被广泛误解的主要原因

让我们谈谈你的观点：

没有算法（但您的意思是很少）：

正如评论中所述，这取决于应用程序。这实际上与TDD无关。拥有很少的算法并不是不测试它们的理由。你可能有几个不同的案例，有很多不同的状态。知道它们按预期工作不是很好吗

成本

当然，它会花费很多钱，如果它是一个小项目，如果您或您的开发人员不熟悉TDD，您可能无法从中获得任何价值。然后再一次，一个小项目可能正是开始它的时候，所以你能赶上下一个更大的项目的速度。这是你必须自己做的计算。我们是程序员，不是经济学家

集成测试

也测试一下

集成测试说“有些东西坏了”，但没有说在哪里

对不起，这个我不明白

难以维护

如果很难维持，那你就是做错了。在更改代码时，首先编写测试，在实现之前更改测试。开发过程中的测试失败是TDD必须完成的。实际上不要引用我的话，那只是我对TDD的有限理解

我发现这是一个关于单元测试的非常好的引用

单元测试应该是规定性的，而不是描述性的。换句话说，单元测试应该定义代码应该做什么，而不是事后说明代码做了什么

归根结底，集成测试和单元测试是两件不同的事情。TDD是一种开发方法，集成测试更多的是从用户的角度验证应用程序是否按预期工作

编辑 社区wiki对集成测试作了如下描述：

在集成测试中，所有输入模块都是具有 已经过单元测试。这些模块按较大的尺寸分组 聚合和集成测试（在集成测试中定义