我目前正在学习单元测试和集成测试,据我了解,单元测试用于测试特定类的逻辑,集成测试用于检查多个类和库的协作。
但是它仅用于测试多个类以及它们是否按预期一起工作,或者在集成测试中访问数据库也有效吗?如果是这样,如果由于服务器端错误而无法建立连接怎么办,虽然代码本身可以按预期工作,但测试不会失败吗?我如何知道在此类测试中使用什么是有效的?
我不明白的第二件事是它们是如何设置的。在我看来,单元测试有一种非常常见的形式,例如:
public class classTest {
@BeforeEach
public void setUp(){
}
@Test
public void testCase(){
}
}
但是集成测试是如何编写的呢?通常是否以相同的方式完成,只是包含更多的类和外部因素,或者是否有其他方法用于此目的?
最佳答案
[... ] is it also valid to access databases in an integration test? [...] How do I know what‘s valid to use in this kind of tests?
单元测试和集成测试之间的区别不在于是否涉及多个组件:即使在单元测试中,如果这些依赖项不会阻止您到达您的单元,您也可以在不模拟所有依赖项的情况下相处。 -测试目标(参见https://stackoverflow.com/a/55583329/5747415)。
单元测试和集成测试的区别在于测试的目标。正如您所写,在单元测试中,您的重点是查找函数、方法或类的逻辑中的错误。显然,在集成测试中,目标是检测在单元测试期间无法找到但可以在集成(子)系统中找到的错误。始终牢记测试目标有助于创建更好的测试并避免集成测试和单元测试之间不必要的冗余。
集成测试的一种形式是交互测试:这里的目标是发现两个或多个组件之间交互中的错误。 (附加组件可以被模拟,也可以不被模拟 - 这同样取决于附加组件是否会妨碍您实现测试目标。)两个组件 A
和 B
交互中的典型问题例如,如果 B
是一个库,则 code> 可以是:组件 A
是否调用组件 B
的正确函数,是组件 B
处于正确状态,可以由 A
通过该函数访问(B
可能尚未初始化),A
正在传递参数的顺序是否正确,参数是否包含预期形式的值,B
是否以预期方式和预期格式返回结果?
集成测试的另一种形式是子系统测试,其中您不关注组件之间的交互,而是查看由集成组件形成的子系统的边界。同样,目标是找到以前的测试(即单元测试和交互测试)无法发现的错误。例如,组件是否集成在正确的版本中,是否可以在集成子系统上执行所需的用例等。
虽然单元测试构成了 test pyramid 的底部,集成测试是一个适用于不同集成级别的概念,甚至可以关注与软件集成策略正交的接口(interface)(例如,在对驱动程序及其相应的硬件设备进行交互测试时)。
Second thing I don‘t understand is how they are set up. [...] how are integration tests written?
这里有一个极端的变化。对于许多集成测试,您可以使用与单元测试相同的测试框架:这些框架中没有任何特定于单元测试的内容。当然,在测试用例中,您必须确保设置实际上将感兴趣的组件组合到正确的版本中。并且,需要决定是否仅使用或模拟其他依赖项(见上文)。
另一个典型场景是使用类似系统测试的设置在完全集成的系统中执行集成测试。这样做通常是为了方便,只是为了避免为不同的集成测试创建不同的特殊设置的麻烦:完全集成的系统只是将它们全部组合在一起。当然,这也有缺点,因为以这种方式按需要执行所有集成测试通常是不可能的或至少是不切实际的。而且,当以这种方式进行集成测试时,集成测试和系统测试之间的界限变得模糊。在这种情况下保持专注意味着您确实必须很好地理解不同的测试目标。
还有混合形式,但这里无法一一描述。仅举一个例子,可以在 LD_PRELOAD
( What is the LD_PRELOAD trick? ) 的帮助下模拟一些共享库。
关于java - 集成测试包含哪些内容以及如何设置它们,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56115219/