你测试的性质

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

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

务实的方法使用两者

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

对我来说，关键的区别在于，集成测试揭示了一个特性是有效的还是坏的，因为它们在接近现实的场景中强调了代码。它们调用一个或多个软件方法或功能，并测试它们是否按预期工作。

相反，测试单个方法的单元测试依赖于(通常是错误的)软件其余部分正常工作的假设，因为它显式地模拟每个依赖项。

因此，当实现某个特性的方法的单元测试显示为绿色时，并不意味着该特性正在工作。

假设你有一个这样的方法:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  Log.TrackTheFactYouDidYourJob();
  return someResults;
}

做某事对你的客户来说非常重要:它是一个特性，是唯一重要的事情。这就是为什么您通常要编写一个Cucumber规范来断言它:您希望验证和交流该特性是否有效。

Feature: To be able to do something
  In order to do something
  As someone
  I want the system to do this thing

Scenario: A sample one
  Given this situation
  When I do something
  Then what I get is what I was expecting for

毫无疑问:如果测试通过了，你就可以断言你交付了一个可以工作的特性。这就是所谓的业务价值。

如果你想为DoSomething写一个单元测试，你应该假装(使用一些模拟)其余的类和方法都在工作(也就是说:方法所使用的所有依赖项都在正确工作)，并断言你的方法是工作的。

在实践中，你可以这样做:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
  return someResults;
}

你可以使用依赖注入，或者一些工厂方法，或者任何模拟框架，或者只是扩展测试中的类。

假设Log.DoSomething()中有一个错误。 幸运的是，Gherkin规范会找到它，您的端到端测试将失败。

这个特性不会工作，因为日志坏了，而不是因为[Do your job with someInput]没有做它的工作。顺便说一下，[Do your job with someInput]是该方法的唯一责任。

同样，假设Log在100个其他特性中使用，在100个其他类的100个其他方法中使用。

是的，100个功能都会失败。但幸运的是，100个端到端测试也失败了，并揭示了这个问题。是的，他们说的是实话。

这是非常有用的信息:我知道我的产品坏了。这也是非常令人困惑的信息:它没有告诉我问题在哪里。它告诉我的是症状，而不是根本原因。

然而，DoSomething的单元测试是绿色的，因为它使用了一个假的日志，被构建为永不崩溃。是的，这显然是在撒谎。它传达了一个坏掉的功能是有效的。它如何有用?

(如果DoSomething()的单元测试失败，请确认:[Do your job with someInput]有一些错误。)

假设这是一个有破碎类的系统:

一个bug就会破坏几个特性，几个集成测试就会失败。

另一方面，相同的错误只会破坏一个单元测试。

现在，比较这两种情况。

同样的错误只会破坏一个单元测试。

使用坏日志的所有功能都是红色的 所有的单元测试都是绿色的，只有Log的单元测试是红色的

实际上，所有使用坏特性的模块的单元测试都是绿色的，因为通过使用模拟，它们删除了依赖项。换句话说，它们运行在一个理想的、完全虚构的世界里。这是唯一隔离和寻找虫子的方法。单元测试意味着模拟。如果你不嘲讽，你就不是单元测试。

的区别

集成测试会告诉你什么是不正常的。但在猜测问题可能在哪里时，它们毫无用处。

单元测试是唯一能告诉您错误确切位置的测试。要绘制此信息，他们必须在模拟环境中运行该方法，在该环境中所有其他依赖项都应该正确工作。

这就是为什么我认为你的句子“或者它只是一个跨越2个类的单元测试”在某种程度上被取代了。一个单元测试不应该跨越2个类。

这个回答基本上是我在这里写的一个总结:单元测试说谎，这就是我喜欢它们的原因。

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

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

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

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

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

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

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

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

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

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

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