我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。
例如，如果我有一个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依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。
其他回答
A little bit academic this question, isn't it? ;-) My point of view: For me an integration test is the test of the whole part, not if two parts out of ten are going together. Our integration test shows, if the master build (containing 40 projects) will succeed. For the projects we have tons of unit tests. The most important thing concerning unit tests for me is, that one unit test must not be dependent on another unit test. So for me both test you describe above are unit tests, if they are independent. For integration tests this need not to be important.
单元测试使用模拟
您正在讨论的是集成测试，它实际上测试了系统的整个集成。但是当你做单元测试时，你应该分别测试每个单元。其他一切都应该被嘲笑。在你的Sentence类的例子中，如果它使用了Word类，那么你的Word类应该被嘲笑。这样，您将只测试您的Sentence类功能。
我也这么做——我把它们都称为单元测试，但在某些时候，我有一个“单元测试”，它涵盖了太多内容，我经常把它重命名为“..IntegrationTest”——只是名字改变了，其他的都没有改变。
我认为从“原子测试”(测试一个微小的类或方法)到单元测试(类级别)和集成测试——然后是功能测试(通常从上到下覆盖了更多的东西)——有一个延续——似乎没有一个干净的分界线。
如果您的测试设置了数据，可能还加载了数据库/文件等，那么它可能更像是一个集成测试(我发现集成测试使用更少的模拟和更多的真实类，但这并不意味着您不能模拟出系统的某些部分)。
我把那些白盒测试类的测试称为单元测试。类需要的任何依赖项都被替换为伪依赖项(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依赖需要一些努力——我不能承认我一直忠实于“单元测试必须是快速的”规则，但如果你是，在一个更大的系统上的好处很快就会显现出来。
在单元测试中，你要测试每个独立的部分:
在集成测试中，您将测试系统的许多模块:
这是当你只使用单元测试时发生的事情(通常两个Windows都可以工作，不幸的是不能一起工作):
来源: source1 source2
