我知道所谓的单元测试和集成测试的教科书定义。 但我想知道的是什么时候该写单元测试…… 我会尽可能多地编写单元测试来覆盖许多类集。
例如，如果我有一个Word类，我会为Word类编写一些单元测试。 然后，我开始编写我的Sentence类，当它需要与Word类交互时，我通常会编写我的单元测试，以便它们同时测试Sentence和Word ... 至少在它们相互作用的地方。
这些测试是否已经成为集成测试，因为它们现在测试了这两个类的集成，或者它只是跨越2个类的单元测试？
一般而言，由于这种不确定性，我很少编写实际的集成测试……或者说，使用成品来查看所有组件是否正常工作就是实际的集成测试，即使它们是手动的，并且很少超出每个单独功能的范围重复。
我是否误解了集成测试，或者集成和单元测试之间真的没有太大区别？
对我来说，关键的区别在于集成测试可以揭示一个功能是正常工作还是出现故障，因为它们在接近实际场景的情况下测试代码。它们调用一个或多个软件方法或功能，并测试它们是否按预期工作。
相反，单元测试测试单个方法，依赖于（通常错误的）假设其余软件已经正确工作，因为它明确地模拟了每个依赖项。
因此，当一个实现某个功能的方法的单元测试通过时，这并不意味着该功能正在工作。
假设您在某个地方有一个类似于以下内容的方法：
public SomeResults DoSomething(someInput) {
var someResult = [Do your job with someInput];
Log.TrackTheFactYouDidYourJob();
return someResults;
}
DoSomething对于你的客户非常重要：它是一个功能，也是唯一重要的事情。这就是为什么你通常会编写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规范将发现它，并且你的端到端测试将失败。Log已损坏，而不是因为[使用某些输入执行你的工作]没有完成任务。顺便说一下，[使用某些输入执行你的工作]是该方法的唯一责任。Log在其他100个特性中使用，在其他100个类的100个其他方法中使用。DoSomething的单元测试是绿色的，因为它使用了一个假的Log，被构建成永远不会出错。是的：它显然是在欺骗。它传递了一个损坏的功能正在运行。它怎么可能有用呢？DoSomething()的单元测试失败，请确保：[以某些输入执行你的工作]有一些错误。）
一个单一的缺陷将破坏多个功能，并导致多个集成测试失败。
另一方面，同一个错误可能只会破坏一个单元测试。
现在，比较这两种情况。
同样的错误只会导致一个单元测试失败。
Log的功能都是红色的Log的单元测试是红色的实际上，所有使用受损功能的模块的单元测试都是绿色的，因为它们使用mocks删除了依赖项。换句话说，它们在一个理想的、完全虚构的世界中运行。这是隔离漏洞并寻找漏洞的唯一方法。单元测试意味着模拟。如果你没有模拟，你就没有进行单元测试。
集成测试告诉你哪些不起作用。但是它们在猜测问题可能出在哪里方面没有用处。
单元测试是唯一能够告诉你bug出现在哪里的测试。要获取这些信息，它们必须在模拟环境中运行该方法，在该环境中，所有其他依赖项应该正确工作。
这就是为什么我认为你的句子“或者它只是跨越2个类的单元测试”有点错位。一个单元测试永远不应该跨越两个类。
这个回复基本上是我在这里写的内容的总结：单元测试会撒谎，所以我喜欢它们。当我编写单元测试时，通过模拟依赖项来限制被测试代码的范围为我当前正在编写的类。如果我正在编写一个 Sentence 类，而 Sentence 类依赖于 Word，则我将使用模拟的 Word。通过模拟 Word，我可以仅关注其接口并测试 Sentence 类与 Word 接口交互时的各种行为。这样，我只测试了 Sentence 的行为和实现，而没有同时测试 Word 的实现。
一旦我编写了单元测试以确保 Sentence 在基于 Word 的接口进行交互时的正确行为，那么我就编写集成测试，以确保我的交互假设是正确的。对此，我提供实际的对象，并编写一个测试，该测试会使用 Sentence 和 Word 两个类，并执行一个将使用这两个类的功能。
我的10个看法 :D
我一直被告知，单元测试是对单个组件的测试 - 应该全面测试其功能。现在，这往往有许多层次，因为大多数组件由更小的部分组成。对我而言，一个单元是系统中的一个功能部分。因此，它必须提供某些价值（例如不是用于字符串解析的方法，而是可能是HtmlSanitizer）。
集成测试是下一步，它将一个或多个组件组合在一起，并确保它们像应该的那样协同工作。当您将HTML输入到HtmlEditControl中时，您不必担心组件如何单独工作，但它会以某种神奇的方式自动检查它是否有效。
这是一条真正可移动的线.. 我更喜欢更专注于让该死的代码完美运行 ^_^
单元测试使用模拟
你说的是整合测试，它实际上测试了系统的整个集成。但是在进行单元测试时，你应该分别测试每个单元。其他所有内容都应该被模拟。所以，在你的Sentence类中，如果它使用Word类，那么你的Word类应该被模拟。这样，你只会测试你的Sentence类功能。
我认为，当你开始思考集成测试时，你更多地在谈论物理层面而不是逻辑层面。
例如，如果你的测试涉及生成内容，那么它就是一个单元测试：如果你的测试只涉及写入磁盘，那么它仍然是一个单元测试，但是一旦你测试I/O和文件内容，那么你就拥有了一个集成测试。当你测试服务内部函数的输出时，这是一个单元测试，但是一旦你进行服务调用并查看函数结果是否相同，那么这就是一个集成测试。
从技术上讲，你无法单元测试一个类。如果你的类由几个其他类组成，那又怎么办？这样是否自动成为了一个集成测试？我不这么认为。
模块X的单元测试是一项测试，该测试仅期望（并检查）模块X中的问题。
许多模块的集成测试是一项测试，该测试期望由这些模块之间的合作引起的问题，因此仅使用单元测试很难发现这些问题。
以以下方式考虑你测试的本质：
请记住，集成测试仍然可以存根/虚拟/模拟掉部分依赖项。这为单元测试和系统测试（最全面的集成测试，测试整个系统）提供了丰富的中间地带。
因此，一种实用的方法是：在可以合理地使用集成测试的情况下灵活依赖它们，并在单元测试可能过于冒险或不方便时使用单元测试。这种思考方式可能比对单元测试和集成测试进行死板的区分更有用。
在我看来，答案是“为什么这很重要？”
是因为单元测试是你应该做的，集成测试是你不应该做的吗？或者反过来？当然不是，你应该尝试两者都做。
是因为单元测试需要快速、独立、可重复、自验证和及时，而集成测试不需要吗？当然不是，所有测试都应该具备这些特点。
是因为你在单元测试中使用模拟对象但在集成测试中不使用模拟对象吗？当然不是。这将意味着如果我有一个有用的集成测试，我不允许为某个部分添加一个模拟对象，担心我必须将我的测试重命名为“单元测试”或将其交给另一个程序员处理。
是因为单元测试测试一个单元，集成测试测试多个单元？当然不是。这在实践中有什么实际重要性呢？关于测试范围的理论讨论在实践中已经崩溃了，因为术语“单元”完全取决于上下文。在类级别，一个单元可能是一个方法。在组件级别，一个单元可能是一个类，而在服务级别，一个单元可能是一个组件。甚至类也使用其他类，那么哪个是单元？
这并不重要。
测试很重要，F.I.R.S.T很重要，在定义上斤斤计较只是浪费时间，只会让新手对测试感到困惑。
