我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。
例如，如果我有一个Word类，我将为Word类编写一些单元测试。然后，我开始编写我的Sentence类，当它需要与Word类交互时，我经常会编写单元测试，这样它们就可以同时测试Sentence和Word……至少在他们相互作用的地方。
这些测试本质上变成集成测试了吗?因为它们现在测试这两个类的集成，还是仅仅是一个跨越两个类的单元测试?
一般来说，由于这条不确定的界线，我很少实际编写集成测试……或者我是否使用成品来查看所有部件是否正常工作，即实际的集成测试，即使它们是手动的，并且很少在每个单独的功能范围之外重复?
我是否误解了集成测试，或者集成测试和单元测试之间真的只有很小的区别?
当前回答
我把那些白盒测试类的测试称为单元测试。类需要的任何依赖项都被替换为伪依赖项(mock)。
集成测试是同时测试多个类及其交互的测试。在这些情况下，只有一些依赖关系是伪造的。
我不会调用Controller的集成测试，除非它们的依赖项之一是真实的(即不是伪造的)(例如IFormsAuthentication)。
Separating the two types of tests is useful for testing the system at different levels. Also, integration tests tend to be long lived, and unit tests are supposed to be quick. The execution speed distinction means they're executed differently. In our dev processes, unit tests are run at check-in (which is fine cos they're super quick), and integration tests are run once/twice per day. I try and run integration tests as often as possible, but usually hitting the database/writing to files/making rpc's/etc slows.
这引出了另一个重要的问题，单元测试应该避免碰到IO(例如磁盘、网络、db)。否则他们会慢很多。设计这些IO依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。
其他回答
使用单一责任设计，它是黑白的。不止一个责任，它是一个集成测试。
通过鸭子测试(看起来，嘎嘎叫，摇摇摆摆，它是一只鸭子)，它只是一个包含不止一个新对象的单元测试。
当你进入mvc并测试它时，控制器测试总是集成的，因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑，我称之为单元测试。
我把那些白盒测试类的测试称为单元测试。类需要的任何依赖项都被替换为伪依赖项(mock)。
集成测试是同时测试多个类及其交互的测试。在这些情况下，只有一些依赖关系是伪造的。
我不会调用Controller的集成测试，除非它们的依赖项之一是真实的(即不是伪造的)(例如IFormsAuthentication)。
Separating the two types of tests is useful for testing the system at different levels. Also, integration tests tend to be long lived, and unit tests are supposed to be quick. The execution speed distinction means they're executed differently. In our dev processes, unit tests are run at check-in (which is fine cos they're super quick), and integration tests are run once/twice per day. I try and run integration tests as often as possible, but usually hitting the database/writing to files/making rpc's/etc slows.
这引出了另一个重要的问题，单元测试应该避免碰到IO(例如磁盘、网络、db)。否则他们会慢很多。设计这些IO依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。
我的10位:D
我总是被告知单元测试是对单个组件的测试——应该充分地进行测试。现在，这往往有很多层次，因为大多数组件是由较小的部件组成的。对我来说，单元是系统的功能部分。所以它必须提供一些有价值的东西(例如，不是字符串解析的方法，而是HtmlSanitizer)。
集成测试是下一步，它采用一个或多个组件，并确保它们按照应有的方式一起工作。然后，你是在担心组件如何单独工作的复杂，但当你输入html到你的htmledcontrol，它以某种神奇的方式知道它是否有效。
这是一条真正可移动的线。我宁愿更专注于让该死的代码完全停止工作^_^
集成测试:测试数据库持久性。 单元测试:模拟数据库访问。对代码方法进行测试。
在我看来，答案是“为什么这很重要?”
是不是因为您只做单元测试而不做集成测试?反之亦然?当然不是，你应该尝试两者兼得。
是因为单元测试需要快速、隔离、可重复、自我验证和及时，而集成测试不需要吗?当然不是，所有的测试都应该是这样。
这是因为您在单元测试中使用模拟，而在集成测试中不使用它们吗?当然不是。这意味着，如果我有一个有用的集成测试，我不允许为某些部分添加模拟，担心我将不得不将我的测试重命名为“单元测试”或将其交给另一个程序员来处理。
是不是因为单元测试测试一个单元，而集成测试测试许多单元?当然不是。这有什么实际意义呢?关于测试范围的理论讨论在实践中无论如何都是行不通的，因为术语“单元”完全依赖于上下文。在类级别上，单元可能是一个方法。在程序集级别上，单元可能是类，而在服务级别上，单元可能是组件。 甚至类也会使用其他类，那么哪个是单位呢?
这无关紧要。
测试很重要，F.I.R.S.T也很重要，对定义吹毛求疵是浪费时间，只会让测试新手感到困惑。
