我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。
例如，如果我有一个Word类，我将为Word类编写一些单元测试。然后，我开始编写我的Sentence类，当它需要与Word类交互时，我经常会编写单元测试，这样它们就可以同时测试Sentence和Word……至少在他们相互作用的地方。
这些测试本质上变成集成测试了吗?因为它们现在测试这两个类的集成，还是仅仅是一个跨越两个类的单元测试?
一般来说，由于这条不确定的界线，我很少实际编写集成测试……或者我是否使用成品来查看所有部件是否正常工作，即实际的集成测试，即使它们是手动的，并且很少在每个单独的功能范围之外重复?
我是否误解了集成测试，或者集成测试和单元测试之间真的只有很小的区别?
当前回答
在单元测试中，你要测试每个独立的部分:
在集成测试中，您将测试系统的许多模块:
这是当你只使用单元测试时发生的事情(通常两个Windows都可以工作，不幸的是不能一起工作):
来源: source1 source2
其他回答
这些测试本质上变成集成测试了吗?因为它们现在测试的是这两个类的集成?或者它只是一个跨越2个类的单元测试?
我认为是和是。跨越2个类的单元测试变成了集成测试。
您可以通过使用mock实现(MockWord类)测试Sentence类来避免这种情况，当系统的这些部分足够大，可以由不同的开发人员实现时，这一点非常重要。在这种情况下，Word是单独的单元测试，句子是在MockWord的帮助下进行单元测试，然后句子是用Word进行集成测试。
以下是真实差异的例子 1) 1,000,000个元素的数组很容易进行单元测试，工作良好。 2) BubbleSort很容易在10个元素的模拟数组上进行单元测试，而且工作得很好 3)集成测试表明有些东西不是很好。
如果这些部分是由一个人开发的，在单元测试BubbleSoft时很可能会发现问题，因为开发人员已经有了真实的数组，他不需要模拟实现。
使用单一责任设计，它是黑白的。不止一个责任，它是一个集成测试。
通过鸭子测试(看起来，嘎嘎叫，摇摇摆摆，它是一只鸭子)，它只是一个包含不止一个新对象的单元测试。
当你进入mvc并测试它时，控制器测试总是集成的，因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑，我称之为单元测试。
此外，重要的是要记住，单元测试和集成测试都可以使用(例如JUnit)自动化和编写。 在JUnit集成测试中，可以使用org.junit.Assume类来测试环境元素(例如，数据库连接)的可用性或其他条件。
我认为，当您开始考虑集成测试时，您更多地是在谈论物理层之间的交叉，而不是逻辑层之间的交叉。
例如，如果您的测试只关心生成内容，那么它就是一个单元测试:如果您的测试只关心写入磁盘，那么它仍然是一个单元测试，但是一旦您同时测试了I/O和文件的内容，那么您就有了一个集成测试。当您在服务中测试函数的输出时，这是单元测试，但一旦您进行服务调用并查看函数结果是否相同，那么这就是集成测试。
从技术上讲，你不能只对一个类进行单元测试。如果您的类是由其他几个类组成的呢?这会自动地使它成为一个集成测试吗?我不这么想。
在单元测试中，你要测试每个独立的部分:
在集成测试中，您将测试系统的许多模块:
这是当你只使用单元测试时发生的事情(通常两个Windows都可以工作，不幸的是不能一起工作):
来源: source1 source2
