集成测试包含什么以及如何设置它们 [英] What are integration tests containing and how to set them up

问题描述

我目前正在学习单元测试和集成测试，据我了解，单元测试用于测试特定类的逻辑，而集成测试则用于检查多个类和库的配合.

I’m currently learning about unit tests and integration testing and as I understood it, unit tests are used to test the logic of a specific class and integration tests are used to check the cooperation of multiple classes and libraries.

但是它是否仅用于测试多个类以及它们是否按预期方式协同工作，还是在集成测试中访问数据库是否还有效?如果是这样，如果由于服务器端错误而无法建立连接怎么办，尽管代码本身可以按预期工作，但测试不会失败吗?我怎么知道在这种测试中可以使用什么?

But is it only used to test multiple classes and if they work together as expected, or is it also valid to access databases in an integration test? If so, what if the connection can‘t be established because of a server sided error, wouldn’t the tests fail, although the code itself would work as expected? How do I know what‘s valid to use in this kind of tests?

我不了解的第二件事是它们的设置方式.在我看来，单元测试有一种很常见的形式，例如:

Second thing I don‘t understand is how they are set up. Unit tests seem to me have a quite common form, like:

public class  classTest {

    @BeforeEach
    public void setUp(){
    }

    @Test
    public void testCase(){
    }
}

但是集成测试如何编写?是否通常以相同的方式进行操作，只是包含更多的类和外部因素，还是有另一种方式使用?

But how are integration tests written? Is it commonly done the same way, just including more classes and external factors or is there another way that is used for that?

推荐答案

[...]在集成测试中访问数据库是否也有效? [...]我怎么知道在这种测试中可以使用什么?

[... ] 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 ).

The distinction between unit-tests and integration tests is not whether or not more than one component is involved: Even in unit-testing you can get along without mocking all your dependencies if these dependencies don't keep you from reaching your unit-testing goals (see https://stackoverflow.com/a/55583329/5747415).

区分单元测试和集成测试的是测试的<目标>目标.如您所写，在单元测试中，您的重点是发现函数，方法或类的逻辑中的错误.显然，在集成测试中，目标是检测在单元测试期间找不到但可以在集成(子)系统中发现的错误.始终牢记测试目标有助于创建更好的测试，并避免集成测试和单元测试之间不必要的冗余.

What distinguishes unit-testing and integration testing is the goal of the test. As you wrote, in unit-testing your focus is on finding bugs in the logic of a function, method or class. In integration testing the goal is then, obviously, to detect bugs that could not be found during unit-testing but can be found in the integrated (sub-)system. Always keeping the test goals in mind helps to create better tests and to avoid unnecessary redundancy between integration tests and unit-tests.

集成测试的一种形式是交互测试:这里的目标是在两个或多个组件之间的交互中发现错误. (是否可以模拟其他组件，这又取决于其他组件是否使您无法达到测试目标.)两个组件A和B的交互作用中的典型问题可能是，例如，如果是一个库:组件A是否调用了组件B的正确功能，组件B是否处于适当的状态，以供A通过该功能访问(B可能尚未初始化)，是A以正确的顺序传递参数，参数是否包含预期格式的值，B是否以预期的方式和预期的格式返回结果?

One flavor of integration testing is interaction testing: Here, the goal is to find bugs in the interaction between two or more components. (Additional components can be mocked, or not - again this depends on whether the additional components keep you from reaching your testing goals.) Typical questions in the interactions of two components A and B could be, for example if B is a library: Is component A calling the right function of component B, is component B in a proper state to be accessed by A via that function (B might not be initialized yet), is A passing the arguments in the correct order, do the arguments contain the values in the expected form, does B give back the results in the expected way and in the expected format?

集成测试的另一种形式是子系统测试，您无需关注组件之间的交互，而是关注由集成组件形成的子系统的边界.而且，目标是找出以前的测试(即单元测试和交互测试)无法找到的错误.例如，将组件集成到正确的版本中，是否可以在集成的子系统上执行所需的用例等.

Another flavor of integration testing is subsystem testing, where you do not focus on the interactions between components, but look at the boundaries of the subsystem formed by the integrated components. And, again, the goal is to find bugs that could not be found by the previous tests (i.e. unit-tests and interaction tests). For example, are the components integrated in the correct versions, can the desired use-cases be exercised on the integrated subsystem etc.

虽然单元测试构成了测试金字塔的底部，集成测试是一个适用于不同集成级别的概念，甚至可以专注于与软件集成策略正交的接口(例如，在对驱动程序及其相应的硬件设备进行交互测试时).

While unit-tests form the bottom of the test pyramid, integration testing is a concept that applies on different levels of integration and can even focus on interfaces orthogonal to the software integration strategy (for example when doing interaction testing of a driver and its corresponding hardware device).

我不了解的第二件事是它们的设置方式. [...]集成测试如何编写?

Second thing I don‘t understand is how they are set up. [...] how are integration tests written?

这里有一个极端的变化.对于许多集成测试，您可以只使用与单元测试相同的测试框架:这些框架中没有特定的单元测试.当然，您必须在测试用例中确保安装程序实际上将感兴趣的组件组合到了正确的版本中.而且，需要确定是否只是使用或嘲笑了其他依赖项(请参见上文).

There is an extreme variation here. For many integration tests you can just use the same testing framework that is used for unit-tests: There is nothing unit-test specific in these frameworks. You will, certainly, in the test cases have to ensure that the setup actually combines the components of interest in their proper versions. And, whether or not additional dependencies are just used or mocked needs to be decided (see above).

另一种典型方案是使用类似系统测试的设置在完全集成的系统中执行集成测试.通常这样做是出于方便，只是为了避免为不同的集成测试创建不同的特殊设置的麻烦:完全集成的系统只是将它们全部组合在一起.当然，这也有缺点，因为以这种方式执行所有集成测试通常是不可能的，或者至少是不切实际的.而且，以这种方式进行集成测试时，集成测试和系统测试之间的界限变得模糊.在这种情况下保持专注意味着您确实必须对不同的测试目标有很好的了解.

Another typical scenario is to perform integration tests in the fully integrated system, using a system-test-like setup. This is often done out of convenience, just to avoid the trouble to create different special setups for the different integration tests: The fully integrated system just has them all combined. Certainly, this has also disadvantages, because it is often impossible or at least impractical to perform all integration tests as desired this way. And, when doing integration testing this way the boundaries between integration testing and system testing get fuzzy. Keeping focused in such a case means you really have to have a good understanding of the different test goals.

也有混合形式，但是这里没有太多描述.仅举一个例子，就有可能借助LD_PRELOAD(什么是LD_PRELOAD技巧?).

There are also mixed forms, but there are too many to describe them here. Just one example, there is a possibility to mock some shared libraries with the help of LD_PRELOAD (What is the LD_PRELOAD trick?).

这篇关于集成测试包含什么以及如何设置它们的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！