当我编写单元测试时，我通过模拟依赖项将被测试代码的范围限制在我当前正在编写的类中。如果我正在编写一个Sentence类，而Sentence依赖于Word，那么我将使用一个模拟Word。通过模拟Word，我可以只关注它的界面，并在与Word界面交互时测试我的Sentence类的各种行为。这样我只测试了Sentence的行为和实现，而没有同时测试Word的实现。

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

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

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

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

我的10位:D

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

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

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

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

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

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

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.

你测试的性质

模块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...

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

务实的方法使用两者

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