单元测试使用模拟

您正在讨论的是集成测试，它实际上测试了系统的整个集成。但是当你做单元测试时，你应该分别测试每个单元。其他一切都应该被嘲笑。在你的Sentence类的例子中，如果它使用了Word类，那么你的Word类应该被嘲笑。这样，您将只测试您的Sentence类功能。

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

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

你测试的性质

模块X的单元测试是仅在模块X中预期(并检查)问题的测试。

许多模块的集成测试是一种预期由模块之间的合作产生的问题的测试，这样单独使用单元测试就很难发现这些问题。

从以下方面考虑测试的性质:

Risk reduction: That's what tests are for. Only a combination of unit tests and integration tests can give you full risk reduction, because on the one hand unit tests can inherently not test the proper interaction between modules and on the other hand integration tests can exercise the functionality of a non-trivial module only to a small degree. Test writing effort: Integration tests can save effort because you may then not need to write stubs/fakes/mocks. But unit tests can save effort, too, when implementing (and maintaining!) those stubs/fakes/mocks happens to be easier than configuring the test setup without them. Test execution delay: Integration tests involving heavyweight operations (such as access to external systems like DBs or remote servers) tend to be slow(er). This means unit tests can be executed far more frequently, which reduces debugging effort if anything fails, because you have a better idea what you have changed in the meantime. This becomes particularly important if you use test-driven development (TDD). Debugging effort: If an integration test fails, but none of the unit tests does, this can be very inconvenient, because there is so much code involved that may contain the problem. This is not a big problem if you have previously changed only a few lines -- but as integration tests run slowly, you perhaps did not run them in such short intervals...

记住，集成测试仍然可能存根/伪造/模拟它的一些依赖项。 这在单元测试和系统测试(最全面的集成测试，测试所有系统)之间提供了大量的中间地带。

务实的方法使用两者

因此，一种务实的方法是:尽可能灵活地依赖集成测试，在风险太大或不方便的地方使用单元测试。 这种思维方式可能比单元测试和集成测试的一些教条主义区分更有用。

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

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

单元测试

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

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

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

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

集成测试

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

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

其他测试术语

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

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

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

我把那些白盒测试类的测试称为单元测试。类需要的任何依赖项都被替换为伪依赖项(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依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。