我们有一个 Web 应用程序（使用 Grails/Groovy），我们编写单元测试和功能测试。
但是，我们没有编写集成测试。
通过单元测试，我们可以发现一些小问题，而且它还可以帮助我们以模块化、简短和易读的方式编写代码库。
功能测试显然可以帮助我们了解功能何时被破坏。
编写集成测试会得到什么？花额外的时间编写这些测试有什么好处？
【问题讨论】：
标签： unit-testing testing integration-testing functional-testing
问题是“编写集成测试会得到什么？花额外的时间编写这些测试有什么好处？”
您的集成测试将确保您的组件与 Web 服务、数据库、会话等横切关注点一起工作。您只需要很少的集成测试 - 正如 @bagheera 对 TestPyramid 的评论。注意你是如何编写集成测试的，因为如果你太过分了，运行所有这些测试真的很慢，而且更难使用。当您将它们与单元测试进行比较时，编写它们并没有太多好处。
附加： 你需要大量的单元测试——你已经有了这个，这是一个好兆头。您不希望在这之间进行测试，这被称为“脏杂种”http://blog.stevensanderson.com/2009/08/24/writing-great-unit-tests-best-and-worst-practises/
【讨论】：
发件人：
http://martinfowler.com/bliki/TestPyramid.html
金字塔还主张有一个中间层的测试 通过应用程序的服务层，我称之为 皮下测试。这些可以提供许多优点 端到端测试，但避免了处理 UI 的许多复杂性 构架。在 Web 应用程序中，这对应于测试 通过 API 层，而金字塔的顶部 UI 部分将 对应于使用 Selenium 或 Sahi 之类的测试..
【讨论】：
除了像@Raedwald 提到的那样检查您的应用程序的管道之外，集成测试非常适合测试您的持久层是否按预期工作。级联设置是否正确？如果在事务期间发生故障，是否一切都正确回滚？使用集成测试而不是功能测试直接检查这些东西通常要容易得多。
【讨论】：
我发现它们对于检查应用程序的“管道”很有用。用于检查您的单元是否连接在一起以及委托对象是否满足它们委托的方法的先决条件。
【讨论】：