集成测试是接口测试吗
是否编写集成测试可能是一个宗教问题：您相信还是不相信它们。 我们甚至所说的集成测试都可能导致无休止的语义争论。
单元测试很容易定义，它们可以测试单个单元：单个类，单个方法，对该方法的行为进行单个声明。 您可能需要模拟（同样，这取决于您对模拟的宗教观点）。
就我所知，集成测试意味着它可以从外到内测试您的代码的已部署（或至少可部署）版本，并尽可能接近“用户”的工作。 如果要构建网站，请使用Selenium WebDriver 。 如果要编写Web服务，请编写一个测试客户端，并向正在运行的服务实例发出请求。 尽可能地超出代码范围，以模仿用户将要执行的操作，并做到这一点。 测试您的代码在集成后是否真正有效。
在这两种极端之间，存在着不同程度的混乱，有人将其称为集成测试。 例如，通过实例化您的请求处理程序类并以编程方式将请求传递给它，从而使其通过数据库运行，来测试Web服务。 这肯定不是单元测试，因为它正在打击数据库。 但是，这不是一个完整的集成测试，因为它错过了一层：如果对服务的HTTP请求从未路由到处理程序，该怎么办呢？
那是什么问题
集成测试很慢。 根据定义，您正在与一个正在运行的应用程序进行交互，然后必须启动，设置，与之交互，拆除并清理。 您将永远无法获得与单元测试一样的速度。 我刚开始使用Visual Studio的后台测试运行程序NCrunch – 很棒 ，但是您不能一直运行缓慢，昂贵的集成测试。 如果您的单元测试需要30秒钟才能运行，我敢打赌，您需要在每次检入之前运行它们。 如果您的集成测试需要20分钟才能运行，那么我敢打赌您不要运行它们 。
您最终可能会复制较低级别的测试。 如果您遵循编写失败的集成测试的典型两级方法，那么编写失败的单元测试然后通过，直到最终您的集成测试通过–集成测试和单元测试的内容之间不可避免地存在重叠。 这是预期的，是设计使然，但看起来像重复。 当您的功能更改时，您将至少有两个测试要更改。
它们并不总是很容易写 。 如果要测试特定案例，则需要完全正确地设置环境。 如果您的应用程序与其他服务/系统交互，则必须对它们进行打桩，以便提供罐装数据。 这可能是不平凡的。 在我工作过的大多数环境中，建立良好的集成测试所产生的最大成本是建立测试基础架构的所有必要弊端：伪造Web服务，第三方，消息传递系统，数据库等等。 这都需要时间和维护，并且会减慢您的开发过程。
最后，集成测试最终可能会反复覆盖应用程序中不感兴趣的部分，这意味着某些更改在更新测试方面非常昂贵。 例如，如果您的应用程序具有中央菜单系统并且您对其进行了更改，则需要更改多少个测试用例？ 如果您的网站有一个登录表单，并且您在很大程度上改变了流程，那么有多少个测试用例需要一个登录用户？
使用页面对象模式之类的模式，您可以对测试进行编码以最大程度地减少这种情况，但是要完全避免此类失败并不总是那么容易。 我在太多公司工作过，即使出于最好的意图，集成测试最终仍以某种工作方式锁定，您要么坚持要么宣布破产，然后删除失败的测试。
那有什么好处呢？
集成测试使您有信心从用户的角度来看应用程序是否可以正常工作。 我绝不建议使用集成测试来涵盖所有可能的极端情况–但是，对某项功能和故障情况的满意测试可以使您对任何给定功能的最基本方面都能发挥作用充满信心。 您可以进行单元测试的复杂情况，但是整体集成测试可以帮助您确保功能已基本集成，并且您不会错过任何明显的单元测试无法涵盖的内容。
您的集成测试可以非常接近验收测试。 如果您使用的是BDD类型方法，那么您应该得到足够技术用户可以理解的，易于阅读的测试定义。 这可以帮助您验证基本功能是否符合用户的期望 ，而不仅仅是其功能是否符合您的期望。
怎么了？
问题是如果很难编写集成测试，就不会编写。 您会发现需要投资的另一项测试基础架构，决定这次不值得，并跳过它。 如果您的方法依靠集成测试来获得应用程序各个部分的适当覆盖率（尤其是对于UI层而言），那么跳过它们意味着您最终得到的覆盖率会比您想要的少得多。
不久前，我正在开发WPF桌面应用程序–我想为其编写集成测试。 用于测试WPF应用程序的不同库基本上都是废话。 他们每个人都无法以某种令人讨厌的关键方式满足我的需求。 我想要的是WPF的WebDriver。 所以我开始写一个。 问题是，Windows UI事件系统的多变意味着这很难 。 在花了很多时间投资于测试基础结构而不是编写集成测试之后，我仍然只有一个几乎无法使用的测试框架，使所有常见情况都无法测试。
因为我无法编写集成测试，并且无法对WPF UI代码进行单元测试，所以我只能对最核心的内部功能进行单元测试-这使WPF UI层的大部分内容都未经测试。 最终，很明显，这是不可接受的，我们回到了编写单元测试（和单元测试）的老式方法，以使用某些源代码以XML编写时获得了接近实际的100％覆盖率。 。
这使我们回到了一个完整的圈子：我们对某个功能拥有良好的单元测试覆盖范围，但是没有集成测试可以验证所有不同的单元是否正确地结合在一起并可以在已部署的应用程序中工作。 但是，如果要权衡取舍的是很少的测试覆盖范围或带有系统盲点的不错的测试覆盖范围，那么最好的选择是什么？
结论
您应该编写集成测试吗？ 如果可以的话，轻松：是的！ 如果您正在编写Web服务，那么为几乎所有其他类型的应用程序编写集成测试要容易得多。 如果您正在编写一个相对传统的，不是JavaScript过多的网站，则WebDriver非常棒（这是获得良好的跨浏览器信心的唯一实用方法）。 如果您要编写非常复杂的UI代码（WPF或JavaScript），则可能很难编写体面的集成测试。
这是您的测试方法与体系结构模糊的地方：尽可能多的体系结构需要简化测试。 对应用程序的结构进行细微的更改可能会更容易获得体面的测试覆盖率：您可以设计应用程序以使其易于独立地测试不同的元素（例如，从业务逻辑服务中分离出UI层）； 您没有得到完全集成的测试，但可以最大程度地减少错误通过漏洞的机会。
从根本上说，是否编写集成测试是一个问题，即要选择哪种体系结构以使您对代码有信心，就必须选择哪种测试。
翻译自: https://www.javacodegeeks.com/2014/03/are-integration-tests-worth-the-hassle.html
集成测试是接口测试吗
