如何进行集成测试？
关于单元测试的文章很多，但我几乎找不到任何关于集成测试的书籍/博客？您能给我建议一些关于这个主题的读物吗？
进行集成测试时要编写哪些测试？ 什么才是好的集成测试？ 等等等等
谢谢
There is so much written about unit testing but I have hardly found any books/blogs about integration testing? Could you please suggest me something to read on this topic?
What tests to write when doing integration testing?
what makes a good integration test?
etc etc
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
JUnit 和 SUnit 之父 Kent Beck 编写的任何内容都是一个很好的起点（对于一般的单元测试/测试写作）。我假设您的意思不是“持续集成”，这是一种基于流程的构建方法（非常酷，当您让它工作时）。
根据我自己的经验，集成测试看起来与常规单元测试非常相似，只是处于更高的级别。更多模拟对象。更多状态初始化。
我相信集成测试就像洋葱。他们有层次。
有些人喜欢“集成”所有组件并测试“整个”产品作为“集成”测试。你当然可以这样做，但我更喜欢一种更渐进的方法。如果您从低级别开始，然后继续在更高的组合层进行测试，那么您将实现集成测试。
Anything written by Kent Beck, father of both JUnit and SUnit, is a great place to start (for unit tests / test writing in general). I'm assuming that you don't mean "continuous integration," which is a process-based build approach (very cool, when you get it working).
In my own experience, integration tests look very similar to regular unit tests, simply at a higher level. More mock objects. More state initialization.
I believe that integration tests are like onions. They have layers.
Some people prefer to "integrate" all of their components and test the "whole" product as an the "integration" test. You can certainly do this, but I prefer a more incremental approach. If you start low-level and then keep testing at higher composition layers, then you will achieve integration testing.
也许通常很难找到有关集成测试的信息，因为它更具体于实际应用程序及其业务用途。尽管如此，这是我的看法。
适用于单元测试的内容也适用于集成测试：模块应该有一种简单的方法来模拟其外部输入（文件、数据库、时间...），以便它们可以与其他单元测试一起进行测试。
但我发现，至少对于面向数据的应用程序来说，非常有用的是能够创建应用程序的“控制台”版本，该版本采用输入文件来完全确定其状态（不依赖于数据库、网络资源...... .)，并将结果输出为另一个文件。例如，然后可以维护一对输入/预期结果文件，并测试回归作为夜间构建的一部分。拥有此控制台版本可以更轻松地编写脚本，并使调试变得异常容易，因为人们可以依赖一个非常稳定的环境，在该环境中很容易重现错误并运行调试器。
Maybe it is generally harder to find information on integration testing because it is much more specific to the actual application and its business use. Nevertheless, here's my take on it.
What applies to unit-tests also applies to integration tests: modules should have an easy way to mock their externals inputs (files, DB, time...), so that they can be tested together with the other unit-tests.
But what I've found extremely useful, at least for data-oriented applications, is to be able to create a "console" version of the application that takes input files that fully determine its state (no dependencies on databases, network resources...), and outputs the result as another file. One can then maintain pairs of inputs / expected results files, and test for regressions as part of nightly builds, for example. Having this console version allows for easier scripting, and makes debugging incredibly easier as one can rely on a very stable environment, where it is easy to reproduce bugs and to run the debugger.
JB Rainsberger 曾写过有关它们的文章。这是 InfoQ 文章的链接，其中包含更多信息。
http://www.infoq.com/news/2009/ 04/jbrains-integration-test-scam
J.B. Rainsberger has written about them. Here's a link to an InfoQ article with more info.
http://www.infoq.com/news/2009/04/jbrains-integration-test-scam