我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。
例如，如果我有一个Word类，我将为Word类编写一些单元测试。然后，我开始编写我的Sentence类，当它需要与Word类交互时，我经常会编写单元测试，这样它们就可以同时测试Sentence和Word……至少在他们相互作用的地方。
这些测试本质上变成集成测试了吗?因为它们现在测试这两个类的集成，还是仅仅是一个跨越两个类的单元测试?
一般来说，由于这条不确定的界线，我很少实际编写集成测试……或者我是否使用成品来查看所有部件是否正常工作，即实际的集成测试，即使它们是手动的，并且很少在每个单独的功能范围之外重复?
我是否误解了集成测试，或者集成测试和单元测试之间真的只有很小的区别?
当前回答
如果class1的单元测试是测试class1的特性，而class2的单元测试是测试它的特性，并且它们不访问数据库，我想我仍然会把两个相互作用的类称为单元测试。
当一个测试运行了我的堆栈的大部分，甚至到达数据库时，我把它称为集成测试。
我真的很喜欢这个问题，因为TDD讨论有时对我来说有点太纯粹了，看到一些具体的例子对我来说是件好事。
其他回答
如果class1的单元测试是测试class1的特性，而class2的单元测试是测试它的特性，并且它们不访问数据库，我想我仍然会把两个相互作用的类称为单元测试。
当一个测试运行了我的堆栈的大部分，甚至到达数据库时，我把它称为集成测试。
我真的很喜欢这个问题，因为TDD讨论有时对我来说有点太纯粹了，看到一些具体的例子对我来说是件好事。
我认为，当您开始考虑集成测试时，您更多地是在谈论物理层之间的交叉，而不是逻辑层之间的交叉。
例如，如果您的测试只关心生成内容，那么它就是一个单元测试:如果您的测试只关心写入磁盘，那么它仍然是一个单元测试，但是一旦您同时测试了I/O和文件的内容，那么您就有了一个集成测试。当您在服务中测试函数的输出时，这是单元测试，但一旦您进行服务调用并查看函数结果是否相同，那么这就是集成测试。
从技术上讲，你不能只对一个类进行单元测试。如果您的类是由其他几个类组成的呢?这会自动地使它成为一个集成测试吗?我不这么想。
我也这么做——我把它们都称为单元测试，但在某些时候，我有一个“单元测试”，它涵盖了太多内容，我经常把它重命名为“..IntegrationTest”——只是名字改变了，其他的都没有改变。
我认为从“原子测试”(测试一个微小的类或方法)到单元测试(类级别)和集成测试——然后是功能测试(通常从上到下覆盖了更多的东西)——有一个延续——似乎没有一个干净的分界线。
如果您的测试设置了数据，可能还加载了数据库/文件等，那么它可能更像是一个集成测试(我发现集成测试使用更少的模拟和更多的真实类，但这并不意味着您不能模拟出系统的某些部分)。
类比的简单解释
上面的例子已经很好了，我就不再重复了。所以我会用例子来帮助你们理解。
集成测试
集成测试检查是否一切都在一起工作。想象一下手表上的一系列齿轮一起工作。一个综合测试是:手表是否显示正确的时间?它还能在3天内显示正确的时间吗?
它只告诉你整个部件是否正常工作。如果它失败了:它不会告诉你它到底在哪里失败。
单元测试
这些都是非常具体的测试类型。它们告诉你一件具体的事情是有效还是失败。这种类型的测试的关键是，它只测试一个特定的东西，同时假设其他一切都正常工作。这是关键。
例子: 让我们用一个例子来详细说明这一点:
Let’s take a car as an example. Integration test for a car: e.g. does the car drive to Woop Woop and back? If it does this, you can safely say that a car is working from an overall view point. It is an integration test. If it fails you have no idea where it is actually failing: is it the radiator, transmission, engine, or carburettor? You have no idea. It could be anything. Unit test for a car: Is the engine is working? This tests assumes that everything else in the car is working just fine. That way, if this particular unit test fails: you can be very confident that the problem lies in the engine – so you can quickly isolate and fix the problem.
使用存根
假设您的汽车集成测试失败。它不能成功地开到埃丘卡。问题出在哪里? 现在让我们假设你的发动机使用一个特殊的燃油喷射系统，这个发动机单元测试也失败了。换句话说，集成测试和发动机单元测试都失败了。那么问题在哪里呢?(给自己10秒钟的时间来回答。) 是发动机出了问题，还是燃油喷射系统出了问题?
你看到问题了吗?你不知道什么是失败。如果你使用不同的外部依赖关系，那么这10个依赖关系中的每一个都可能导致问题——你不知道从哪里开始。这就是为什么单元测试使用存根来假设其他一切都正常工作。
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.
