此外，重要的是要记住，单元测试和集成测试都可以使用(例如JUnit)自动化和编写。 在JUnit集成测试中，可以使用org.junit.Assume类来测试环境元素(例如，数据库连接)的可用性或其他条件。

我的10位:D

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

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

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

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

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

Wikipedia将单元定义为应用程序中最小的可测试部分，在Java/ c#中是一个方法。但是在你的单词和句子类的例子中，我可能只会为句子写测试，因为我可能会发现使用一个模拟单词类来测试句子类是多余的。所以句子是我的单位，单词是这个单位的实现细节。

这些测试本质上变成集成测试了吗?因为它们现在测试的是这两个类的集成?或者它只是一个跨越2个类的单元测试?

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

您可以通过使用mock实现(MockWord类)测试Sentence类来避免这种情况，当系统的这些部分足够大，可以由不同的开发人员实现时，这一点非常重要。在这种情况下，Word是单独的单元测试，句子是在MockWord的帮助下进行单元测试，然后句子是用Word进行集成测试。

以下是真实差异的例子 1) 1,000,000个元素的数组很容易进行单元测试，工作良好。 2) BubbleSort很容易在10个元素的模拟数组上进行单元测试，而且工作得很好 3)集成测试表明有些东西不是很好。

如果这些部分是由一个人开发的，在单元测试BubbleSoft时很可能会发现问题，因为开发人员已经有了真实的数组，他不需要模拟实现。

我把那些白盒测试类的测试称为单元测试。类需要的任何依赖项都被替换为伪依赖项(mock)。

集成测试是同时测试多个类及其交互的测试。在这些情况下，只有一些依赖关系是伪造的。

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

Separating the two types of tests is useful for testing the system at different levels. Also, integration tests tend to be long lived, and unit tests are supposed to be quick. The execution speed distinction means they're executed differently. In our dev processes, unit tests are run at check-in (which is fine cos they're super quick), and integration tests are run once/twice per day. I try and run integration tests as often as possible, but usually hitting the database/writing to files/making rpc's/etc slows.

这引出了另一个重要的问题，单元测试应该避免碰到IO(例如磁盘、网络、db)。否则他们会慢很多。设计这些IO依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。

集成测试:测试数据库持久性。 单元测试:模拟数据库访问。对代码方法进行测试。