我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。
例如，如果我有一个Word类，我将为Word类编写一些单元测试。然后，我开始编写我的Sentence类，当它需要与Word类交互时，我经常会编写单元测试，这样它们就可以同时测试Sentence和Word……至少在他们相互作用的地方。
这些测试本质上变成集成测试了吗?因为它们现在测试这两个类的集成，还是仅仅是一个跨越两个类的单元测试?
一般来说，由于这条不确定的界线，我很少实际编写集成测试……或者我是否使用成品来查看所有部件是否正常工作，即实际的集成测试，即使它们是手动的，并且很少在每个单独的功能范围之外重复?
我是否误解了集成测试，或者集成测试和单元测试之间真的只有很小的区别?
当前回答
使用单一责任设计，它是黑白的。不止一个责任，它是一个集成测试。
通过鸭子测试(看起来，嘎嘎叫，摇摇摆摆，它是一只鸭子)，它只是一个包含不止一个新对象的单元测试。
当你进入mvc并测试它时，控制器测试总是集成的，因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑，我称之为单元测试。
其他回答
单元测试是一种测试方法，用于验证源代码的各个单元是否正常工作。
集成测试是软件测试的一个阶段，在这个阶段中，各个软件模块被组合起来并作为一个组进行测试。
Wikipedia将单元定义为应用程序中最小的可测试部分，在Java/ c#中是一个方法。但是在你的单词和句子类的例子中，我可能只会为句子写测试，因为我可能会发现使用一个模拟单词类来测试句子类是多余的。所以句子是我的单位，单词是这个单位的实现细节。
当我编写单元测试时，我通过模拟依赖项将被测试代码的范围限制在我当前正在编写的类中。如果我正在编写一个Sentence类，而Sentence依赖于Word，那么我将使用一个模拟Word。通过模拟Word，我可以只关注它的界面，并在与Word界面交互时测试我的Sentence类的各种行为。这样我只测试了Sentence的行为和实现，而没有同时测试Word的实现。
一旦我编写了单元测试，以确保Sentence在基于Word的界面与Word交互时行为正确，然后我编写集成测试，以确保我对交互的假设是正确的。为此，我提供了实际的对象，并编写了一个测试，练习一个最终将同时使用Sentence和Word的功能。
你测试的性质
模块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...
记住，集成测试仍然可能存根/伪造/模拟它的一些依赖项。 这在单元测试和系统测试(最全面的集成测试，测试所有系统)之间提供了大量的中间地带。
务实的方法使用两者
因此，一种务实的方法是:尽可能灵活地依赖集成测试，在风险太大或不方便的地方使用单元测试。 这种思维方式可能比单元测试和集成测试的一些教条主义区分更有用。
如果class1的单元测试是测试class1的特性，而class2的单元测试是测试它的特性，并且它们不访问数据库，我想我仍然会把两个相互作用的类称为单元测试。
当一个测试运行了我的堆栈的大部分，甚至到达数据库时，我把它称为集成测试。
我真的很喜欢这个问题，因为TDD讨论有时对我来说有点太纯粹了，看到一些具体的例子对我来说是件好事。
单元测试是针对工作单元或代码块进行测试。通常由单个开发人员执行。
集成测试是指当开发人员将其代码提交到源代码控制存储库时，最好在集成服务器上执行的测试。集成测试可以由Cruise Control等实用程序执行。
因此，您可以执行单元测试来验证您构建的工作单元是否正常工作，然后集成测试验证您添加到存储库中的任何内容都没有破坏其他内容。
