A little bit academic this question, isn't it? ;-) My point of view: For me an integration test is the test of the whole part, not if two parts out of ten are going together. Our integration test shows, if the master build (containing 40 projects) will succeed. For the projects we have tons of unit tests. The most important thing concerning unit tests for me is, that one unit test must not be dependent on another unit test. So for me both test you describe above are unit tests, if they are independent. For integration tests this need not to be important.

我的10位:D

我总是被告知单元测试是对单个组件的测试——应该充分地进行测试。现在，这往往有很多层次，因为大多数组件是由较小的部件组成的。对我来说，单元是系统的功能部分。所以它必须提供一些有价值的东西(例如，不是字符串解析的方法，而是HtmlSanitizer)。

集成测试是下一步，它采用一个或多个组件，并确保它们按照应有的方式一起工作。然后，你是在担心组件如何单独工作的复杂，但当你输入html到你的htmledcontrol，它以某种神奇的方式知道它是否有效。

这是一条真正可移动的线。我宁愿更专注于让该死的代码完全停止工作^_^

使用单一责任设计，它是黑白的。不止一个责任，它是一个集成测试。

通过鸭子测试(看起来，嘎嘎叫，摇摇摆摆，它是一只鸭子)，它只是一个包含不止一个新对象的单元测试。

当你进入mvc并测试它时，控制器测试总是集成的，因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑，我称之为单元测试。

我认为，当您开始考虑集成测试时，您更多地是在谈论物理层之间的交叉，而不是逻辑层之间的交叉。

例如，如果您的测试只关心生成内容，那么它就是一个单元测试:如果您的测试只关心写入磁盘，那么它仍然是一个单元测试，但是一旦您同时测试了I/O和文件的内容，那么您就有了一个集成测试。当您在服务中测试函数的输出时，这是单元测试，但一旦您进行服务调用并查看函数结果是否相同，那么这就是集成测试。

从技术上讲，你不能只对一个类进行单元测试。如果您的类是由其他几个类组成的呢?这会自动地使它成为一个集成测试吗?我不这么想。

类比的简单解释

上面的例子已经很好了，我就不再重复了。所以我会用例子来帮助你们理解。

集成测试

集成测试检查是否一切都在一起工作。想象一下手表上的一系列齿轮一起工作。一个综合测试是:手表是否显示正确的时间?它还能在3天内显示正确的时间吗?

它只告诉你整个部件是否正常工作。如果它失败了:它不会告诉你它到底在哪里失败。

单元测试

这些都是非常具体的测试类型。它们告诉你一件具体的事情是有效还是失败。这种类型的测试的关键是，它只测试一个特定的东西，同时假设其他一切都正常工作。这是关键。

例子: 让我们用一个例子来详细说明这一点:

Let’s take a car as an example. Integration test for a car: e.g. does the car drive to Woop Woop and back? If it does this, you can safely say that a car is working from an overall view point. It is an integration test. If it fails you have no idea where it is actually failing: is it the radiator, transmission, engine, or carburettor? You have no idea. It could be anything. Unit test for a car: Is the engine is working? This tests assumes that everything else in the car is working just fine. That way, if this particular unit test fails: you can be very confident that the problem lies in the engine – so you can quickly isolate and fix the problem.

使用存根

假设您的汽车集成测试失败。它不能成功地开到埃丘卡。问题出在哪里? 现在让我们假设你的发动机使用一个特殊的燃油喷射系统，这个发动机单元测试也失败了。换句话说，集成测试和发动机单元测试都失败了。那么问题在哪里呢?(给自己10秒钟的时间来回答。) 是发动机出了问题，还是燃油喷射系统出了问题?

你看到问题了吗?你不知道什么是失败。如果你使用不同的外部依赖关系，那么这10个依赖关系中的每一个都可能导致问题——你不知道从哪里开始。这就是为什么单元测试使用存根来假设其他一切都正常工作。

我在采访中经常被问到这个问题。到目前为止，我一直在吹嘘我的专业知识，并对组件测试和验收测试侃侃而谈。

多年来，我只了解集成和单元测试。作为一个单独的开发人员，我可以编写单元测试来磨练我的技能，但我并不总是这么做。

单元测试

这是一个关键的区别。单元测试易于实现和执行，理想情况下不需要依赖。这就是嘲笑的意义所在。不模仿所有内容通常更容易，特别是在覆盖您所编写的其他函数的情况下。也许更简单，但这不是单元测试的思想。

我要重申，单元测试意味着易于运行且规模小。它们的失败可以让我们立即了解bug是在哪里引入的。

下面是测试的等级，从底部的廉价和丰富到顶部的缓慢、昂贵和很少:

还有几个层可以概念化，但为了清晰起见，省略了这些层。

集成测试

通过集成测试，您可以考虑引入严重的外部依赖项，例如虚拟机、虚拟网络和设备。可能您可以使用实际的调制解调器、路由器和防火墙，只要这些花费是合理的。

这些不会在本地运行，而是在构建服务器上运行。本地Jenkins和基于云的CI提供商的组合满足了这一需求。

其他测试术语

这是我在工业界工作了几年的体会。我们可以讨论组件测试，并得到一个定义，但如果这个定义没有被广泛使用，那么它就失去了价值。

验收测试就是我们所说的业务单元或客户需求。这些将引导一切的方向，并位于金字塔的顶端(想象一个美元符号)。

端到端测试是集成测试的同义词，但我在网上注意到它被放在上面。我想它可能与验收测试和集成测试更相关，后者往往更详细，涉众的兴趣更少(尽管部门内部有巨大的兴趣)。