即使集成测试已经涵盖了代码，我是否应该通过单元测试来涵盖代码？答案

【问题标题】：Should I cover the code by unit tests even it already has been covered by integration tests?即使集成测试已经涵盖了代码，我是否应该通过单元测试来涵盖代码？
【发布时间】：2017-02-27 22:59:44
【问题描述】：

假设我们有一些带有 REST API 的 Web 服务，并且为了说明，有一些使用数据库的工作。在我看来，测试此应用程序的最基本方法是集成测试，它从 REST API 顶部对其进行测试，以验证它是否正常工作。但是使用一些模拟技术的单元测试呢？在专业开发中（当然人力资源有限）是否真的有必要用单元测试来覆盖代码，即使它已经被集成测试覆盖了？

谢谢

【问题讨论】：

我将把它留在这里作为评论：D 可能值得一看 youtube.com/watch?v=VDfX44fZoMc
这是非常好的解释，谢谢！但是我有这样的感觉，在通常的公司实践中，即使它是最好的解决方案，也几乎不可能编写那个人推荐的如此高度结构化的单元测试。所以我在通常的企业 Java 项目中看到的是非常孤立的单元测试，它们在一致性上相互独立，这些测试能力非常值得怀疑。
stackoverflow.com/questions/42469686/… 刚刚在这里回答了同样的问题，将重新发布答案，因为它没有任何赞成/接受，因此无法投票关闭为重复项
@Jurass 我远非知识渊博，我想说对整个问题有很大的意见。我只是碰巧同意单元测试实际上不是为了断言系统正确性而是为了代码设计的目的，单元正确性排在第二位。从这个意义上说，我想说两种测试的目的是完全不同的，即使相同的代码被覆盖两次。视频中的他们并不是告诉您不要进行集成测试，而是要在系统的前沿进行，这样可以防止您的双重覆盖问题，也许？对不起，我不知道：D
这不是“必要的”，尽管进行单元测试肯定有好处。 ;) 仅进行单元测试是不够的，因为某些错误确实发生在集成级别。单元测试相对于集成测试的好处是快速迭代和查明问题的能力。与一大堆单元测试相比，集成套件的运行时间更长。同样，当集成测试失败时，您将花费更多时间来跟踪根本原因。它们更容易变脆。简而言之，进行单元测试会让你的生活更轻松。您听说过测试金字塔的概念吗？

标签： unit-testing mocking integration-testing use-case

【解决方案1】：

好问题。当然，答案将基于意见，但希望它们基于实际的现实世界经验。

就我而言，这些年来我编写了数千个 JUnit/TestNG 测试，并且碰巧为 Java 开发了一个高级测试库（模拟 + 代码覆盖率 + 集成测试）。

所以，IMO，当您已经拥有一个好的集成测试套件时，编写单元测试是没有必要的，也没有效率。

当然，集成测试确实需要更长的时间才能运行，但它们应该仍然足够快，以至于开发人员不会因此而放弃运行它们。这很重要：如果开发人员在开发新代码或修改时仍然可以高效地运行一个测试、一个测试类等，那就没问题了。因此，请避免使测试执行过于缓慢/痛苦的集成测试方法（例如 Selenium）。

对集成测试的另一个批评是，它们使找出测试失败的根本原因变得更加困难。不过，这在实践中并不是一个足够大的问题。

Martin Fowler 在他的Unit Test 文章中提出了同样的两点。

【讨论】：