集成测试和单元测试有什么区别？ [关闭]

本文翻译自：What is the difference between integration and unit tests? [closed]

I know the so-called textbook definition of unit tests and integration tests. 我知道单元测试和集成测试的所谓教科书定义。 What I am curious about is when it is time to write unit tests... I will write them to cover as many sets of classes as possible. 我很好奇的是什么时候编写单元测试了……我将编写它们以涵盖尽可能多的类集。

For example, if I have a Word class, I will write some unit tests for the Word class. 举例来说，如果我有一个Word类，我会写的一些单元测试Word类。 Then, I begin writing my Sentence class, and when it needs to interact with the Word class, I will often write my unit tests such that they test both Sentence and Word ... at least in the places where they interact. 然后，我开始编写Sentence类，当它需要与Word类交互时，我通常会编写单元测试，以便它们至少在交互的地方测试Sentence和Word 。

Have these tests essentially become integration tests because they now test the integration of these 2 classes, or is it just a unit test that spans 2 classes? 这些测试是否实质上已经成为集成测试，因为它们现在可以测试这两个类的集成，还是仅仅是跨越两个类的单元测试？

In general, because of this uncertain line, I will rarely actually write integration tests... or is my using the finished product to see if all the pieces work properly the actual integration tests, even though they are manual and rarely repeated beyond the scope of each individual feature? 总的来说，由于这条线的不确定性，我很少实际编写集成测试……或者是我使用最终产品来查看所有部件在实际的集成测试中是否都能正常工作，即使它们是手动的并且很少超出范围每个单独的功能？

Am I misunderstanding integration tests, or is there really just very little difference between integration and unit tests? 我是误解了集成测试，还是集成测试和单元测试之间的区别真的很小？

---

#1楼

参考：https://stackoom.com/question/2nQ/集成测试和单元测试有什么区别-关闭

---

#2楼

using Single responsibility design, its black and white. 采用单一职责设计，黑色和白色。 More than 1 responsibility, its an integration test. 1个以上的职责，它是一个集成测试。

By the duck test (looks, quacks, waddles, its a duck), its just a unit test with more than 1 newed object in it. 通过鸭子测试（外观，嘎嘎，蹒跚，鸭子），它只是一个单元测试，其中包含多个新对象。

When you get into mvc and testing it, controller tests are always integration, because the controller contains both a model unit and a view unit. 进入mvc并进行测试时，控制器测试始终是集成的，因为控制器既包含模型单元又包含视图单元。 Testing logic in that model, I would call a unit test. 在该模型中测试逻辑，我称之为单元测试。

---

#3楼

I think when you start thinking about integration tests, you are speaking more of a cross between physical layers rather than logical layers. 我认为当您开始考虑集成测试时，您在说的更多是物理层之间的交叉而不是逻辑层。

For example, if your tests concern itself with generating content, it's a unit test: if your test concerns itself with just writing to disk, it's still a unit test, but once you test for both I/O AND the content of the file, then you have yourself an integration test. 例如，如果您的测试涉及生成内容，那么它就是一个单元测试：如果您的测试仅涉及写入磁盘，那么它仍然是一个单元测试，但是一旦测试了I / O和文件的内容，那么您就需要进行集成测试。 When you test the output of a function within a service, it's a unit-test, but once you make a service call and see if the function result is the same, then that's an integration test. 在服务中测试功能的输出时，这是一个单元测试，但是一旦进行服务调用，然后查看功能结果是否相同，那就是集成测试。

Technically you cannot unit test just-one-class anyway. 从技术上讲，您无论如何不能只对一个类进行单元测试。 What if your class is composed with several other classes? 如果您的课程由其他几个课程组成，该怎么办？ Does that automatically make it an integration test? 这会自动使其成为集成测试吗？ I don't think so. 我不这么认为。

---

#4楼

Unit testing is testing against a unit of work or a block of code if you like. 如果需要，单元测试就是针对工作单元或代码块进行测试。 Usually performed by a single developer. 通常由单个开发人员执行。

Integration testing refers to the test that is performed, preferably on an integration server, when a developer commits their code to a source control repository. 集成测试是指当开发人员将其代码提交到源代码控制存储库时，最好在集成服务器上执行的测试。 Integration testing might be performed by utilities such as Cruise Control. 集成测试可能由Cruise Control等实用程序执行。

So you do your unit testing to validate that the unit of work you have built is working and then the integration test validates that whatever you have added to the repository didn't break something else. 因此，您进行单元测试以验证所构建的工作单元是否正常运行，然后集成测试将验证您添加到存储库中的任何内容都不会破​​坏其他功能。

---

#5楼

I think I would still call a couple of interacting classes a unit test provided that the unit tests for class1 are testing class1's features, and the unit tests for class2 are testing its features, and also that they are not hitting the database. 我想我仍然将几个交互的类称为单元测试，条件是class1的单元测试正在测试class1的功能，class2的单元测试正在测试其功能，并且它们没有触及数据库。

I call a test an integration test when it runs through most of my stack and even hits the database. 当它贯穿我的大部分堆栈甚至访问数据库时，我将其称为集成测试。

I really like this question, because TDD discussion sometimes feels a bit too purist to me, and it's good for me to see some concrete examples. 我真的很喜欢这个问题，因为TDD讨论有时对我来说太过纯粹了，对我来说，看一些具体的例子对我很有好处。

---

#6楼

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. 我们的集成测试表明，主构建（包含40个项目）能否成功。 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. 对于集成测试，这并不重要。