我知道所谓的单元测试和集成测试的教科书定义。我好奇的是什么时候该写单元测试了……我将写它们来覆盖尽可能多的类集。

例如,如果我有一个Word类,我将为Word类编写一些单元测试。然后,我开始编写我的Sentence类,当它需要与Word类交互时,我经常会编写单元测试,这样它们就可以同时测试Sentence和Word……至少在他们相互作用的地方。

这些测试本质上变成集成测试了吗?因为它们现在测试这两个类的集成,还是仅仅是一个跨越两个类的单元测试?

一般来说,由于这条不确定的界线,我很少实际编写集成测试……或者我是否使用成品来查看所有部件是否正常工作,即实际的集成测试,即使它们是手动的,并且很少在每个单独的功能范围之外重复?

我是否误解了集成测试,或者集成测试和单元测试之间真的只有很小的区别?


当前回答

使用单一责任设计,它是黑白的。不止一个责任,它是一个集成测试。

通过鸭子测试(看起来,嘎嘎叫,摇摇摆摆,它是一只鸭子),它只是一个包含不止一个新对象的单元测试。

当你进入mvc并测试它时,控制器测试总是集成的,因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑,我称之为单元测试。

其他回答

单元测试使用模拟

您正在讨论的是集成测试,它实际上测试了系统的整个集成。但是当你做单元测试时,你应该分别测试每个单元。其他一切都应该被嘲笑。在你的Sentence类的例子中,如果它使用了Word类,那么你的Word类应该被嘲笑。这样,您将只测试您的Sentence类功能。

使用单一责任设计,它是黑白的。不止一个责任,它是一个集成测试。

通过鸭子测试(看起来,嘎嘎叫,摇摇摆摆,它是一只鸭子),它只是一个包含不止一个新对象的单元测试。

当你进入mvc并测试它时,控制器测试总是集成的,因为控制器包含一个模型单元和一个视图单元。在这个模型中测试逻辑,我称之为单元测试。

此外,重要的是要记住,单元测试和集成测试都可以使用(例如JUnit)自动化和编写。 在JUnit集成测试中,可以使用org.junit.Assume类来测试环境元素(例如,数据库连接)的可用性或其他条件。

如果class1的单元测试是测试class1的特性,而class2的单元测试是测试它的特性,并且它们不访问数据库,我想我仍然会把两个相互作用的类称为单元测试。

当一个测试运行了我的堆栈的大部分,甚至到达数据库时,我把它称为集成测试。

我真的很喜欢这个问题,因为TDD讨论有时对我来说有点太纯粹了,看到一些具体的例子对我来说是件好事。

我也这么做——我把它们都称为单元测试,但在某些时候,我有一个“单元测试”,它涵盖了太多内容,我经常把它重命名为“..IntegrationTest”——只是名字改变了,其他的都没有改变。

我认为从“原子测试”(测试一个微小的类或方法)到单元测试(类级别)和集成测试——然后是功能测试(通常从上到下覆盖了更多的东西)——有一个延续——似乎没有一个干净的分界线。

如果您的测试设置了数据,可能还加载了数据库/文件等,那么它可能更像是一个集成测试(我发现集成测试使用更少的模拟和更多的真实类,但这并不意味着您不能模拟出系统的某些部分)。