我知道单元测试和集成测试的所谓教科书定义。我很好奇的是什么时候编写单元测试了……我将编写它们以覆盖尽可能多的类集。

例如，如果我有一个Word类，我将为Word类编写一些单元测试。然后，我开始编写我的Sentence类，当它需要与Word类交互时，我经常会编写单元测试，以便它们至少在测试中同时测试Sentence和'Word`...。他们互动的地方。

这些测试是否实质上已经成为集成测试，因为它们现在可以测试这两个类的集成，还是仅仅是跨越两个类的单元测试？

总的来说，由于这条线的不确定性，我很少实际编写集成测试……或者是我使用最终产品来查看所有部件在实际的集成测试中是否正常工作，即使它们是手动的并且很少超出范围每个单独的功能？

我是误解了集成测试，还是集成和单元测试之间的区别真的很小？

编辑

感谢大家的所有好评！我认为从各种各样的答案中可以很明显地看出，单元测试和集成测试之间的界线肯定是一条模糊的界线，尝试找出哪些是真正的焦点应该留在代码上可能有些花哨(感谢@Rob Cooper )。另外，很抱歉，但我不会接受任何答案，因为太多的答案太好了，而且看起来确实很主观。

解决方案

回答

采用单一职责设计，黑色和白色。 1个以上的职责，它是一个集成测试。

通过鸭子测试(外观，嘎嘎，蹒跚，鸭子)，它只是一个单元测试，其中包含多个新对象。

进入mvc并对其进行测试时，控制器测试始终是集成的，因为控制器既包含模型单元又包含视图单元。在该模型中测试逻辑，我称之为单元测试。

回答

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

例如，如果测试涉及生成内容，那么它就是一个单元测试：如果测试仅涉及写入磁盘，那么它仍然是一个单元测试，但是一旦测试了I / O和文件的内容，那么我们就需要进行集成测试。在服务中测试功能的输出时，这是一个单元测试，但是一旦进行服务调用，然后查看功能结果是否相同，那就是集成测试。

从技术上讲，我们无论如何不能只对一个类进行单元测试。如果课程由其他几个课程组成，该怎么办？这会自动使它成为集成测试吗？我不这么认为。

回答

单元测试是针对工作单元或者代码块(如果我们愿意)进行测试。通常由单个开发人员执行。

集成测试是指当开发人员将其代码提交到源代码控制存储库时，最好在集成服务器上执行的测试。集成测试可能由Cruise Control之类的实用程序执行。

因此，我们进行单元测试以验证所构建的工作单元是否正常运行，然后集成测试将验证我们添加到存储库中的任何内容是否不会破坏其他功能。

回答

我想我仍然将几个交互的类称为单元测试，条件是class1的单元测试正在测试class1的功能，class2的单元测试正在测试其功能，并且它们没有触及数据库。

当它贯穿我的大部分堆栈甚至访问数据库时，我将其称为集成测试。

我真的很喜欢这个问题，因为TDD讨论有时对我来说过于纯粹，对我来说，看到一些具体的例子对我很有好处。

回答

这个问题有点学术，不是吗？ ;-)
我的观点：
对我而言，集成测试是整个部分的测试，而不是十分之二的测试。
我们的集成测试表明，主构建(包含40个项目)是否会成功。
对于项目，我们有大量的单元测试。
对我而言，与单元测试有关的最重要的事情是，一个单元测试一定不能依赖于另一个单元测试。因此，对我来说，我们上面描述的两个测试都是独立的单元测试。对于集成测试，这并不重要。

回答

我做同样的事情，我称它们为所有单元测试，但是在某个时候，我有一个涵盖了很多内容的"单元测试"，所以我经常将其重命名为" ..IntegrationTest"，只是名称更改，其他都没有更改。

我认为这是从"原子测试"(测试一个微小的类或者方法)到单元测试(类级别)，集成测试，然后是功能测试(通常从上到下覆盖更多内容)的延续。似乎并不是一个明确的起点。

如果测试设置了数据，并且可能加载了数据库/文件等，那么它可能更多的是集成测试(我发现集成测试使用的模拟次数更少，而实际类更多，但这并不意味着我们无法模拟掉一些的系统)。

回答

我的10位：D

经常有人告诉我，单元测试是对单个组件的测试，应充分利用它。现在，由于大多数组件是由较小的零件制成的，因此它趋向于具有多个层次。对我来说，单元是系统的功能部分。因此，它必须提供一些有价值的东西(即，不是用于字符串解析的方法，而可能是HtmlSanitizer)。

集成测试是下一步的工作，它采用一个或者多个组件并确保它们可以正常工作。以某种方式神奇地知道它是否有效。

它实际上是一条可移动的线..我宁愿将精力更多地放在使该死的代码完全停止工作上^ _ ^

回答

单元测试是一种测试方法，用于验证源代码的各个单元是否正常工作。

集成测试是软件测试的阶段，在此阶段中，各个软件模块被组合在一起并作为一个整体进行测试。

Wikipedia将单位定义为应用程序中可测试的最小部分，在Java / C中是一种方法。但是在单词和句子类的示例中，我可能只是编写句子的测试，因为使用模拟单词类来测试句子类可能会显得过于刻板。因此，句子将是我的单元，而单词是该单元的实现细节。

回答

我称单元测试为那些白盒测试为类的测试。类要求的所有依赖关系都将被伪造的(模拟)替换。

集成测试是同时测试多个类及其交互的测试。在这些情况下，只有某些依赖项是伪造的/模拟的。

除非它们的依赖关系之一是真实的依赖关系(即不是伪造的)(例如IFormsAuthentication)，否则我不会调用Controller的集成测试。

分离两种类型的测试对于在不同级别上测试系统很有用。而且，集成测试往往寿命很长，而单元测试则应该很快。执行速度的区别意味着它们的执行方式不同。在我们的开发流程中，单元测试在签入时运行(这很不错，因为它们非常快)，集成测试每天运行一次/两次。我尝试并尽可能多地运行集成测试，但通常会打数据库/将文件写入文件/使rpc / etc变慢。

这就提出了另一个重要的观点，单元测试应该避免命中IO(例如磁盘，网络，数据库)。否则，它们会大大减慢速度。设计这些IO依赖项需要花些力气，我不能承认我一直忠实于"单元测试必须快速"的规则，但是如果我们愿意的话，那么更大系统的好处就会很快显现出来。

回答

当我编写单元测试时，我通过模拟依赖关系将测试代码的范围限制为当前正在编写的类。如果我正在编写Sentence类，并且Sentence对Word有依赖性，则将使用模拟Word。通过模拟Word，我可以只专注于其接口，并测试Sentence类与Word的接口交互时的各种行为。这样，我仅测试句子的行为和实现，而不同时测试Word的实现。

一旦编写了单元测试以确保Sentence在基于Word的界面与Word交互时行为正确，然后编写集成测试以确保我对交互的假设正确。为此，我提供了实际的对象并编写了一个测试该功能的测试，该测试最终将同时使用Sentence和Word。

回答

Have these tests essentially become integration tests because they now test the integration of these 2 classes? Or is it just a unit test that spans 2 classes?

我认为是的，是的。跨越2个类的单元测试成为集成测试。

我们可以通过使用模拟实现MockWord类测试Sentence类来避免这种情况，当系统的那些部分足够大以至于可以由不同的开发人员来实现时，这一点很重要。在这种情况下，Word单独进行单元测试，Sentence在MockWord的帮助下进行单元测试，然后Sentence与Word进行集成测试。

实际差异的例子如下
1)1,000,000个元素的数组很容易进行单元测试，并且效果很好。
2)BubbleSort易于在包含10个元素的模拟数组上进行单元测试，并且效果很好
3)集成测试表明有些问题不是很好。

如果这些部分是由单个人开发的，则在单元测试BubbleSoft时会发现最可能出现的问题，这仅仅是因为开发人员已经拥有实际的数组，并且他不需要模拟实现。

回答

单元测试使用模拟

我们正在谈论的是集成测试，它实际上测试了系统的整个集成。但是，当我们进行单元测试时，实际上应该分别测试每个单元。其他一切都应该被嘲笑。因此，在Sentence类的情况下，如果它使用Word类，则应该模拟Word类。这样，我们将仅测试Sentence类功能。