保持单元测试分离和独立 [英] Keeping unit tests separate and independent

问题描述

我无法让我的单元测试保持相互独立.例如，我有一个带有两个 append 方法的链表，一个接受单个元素并将其附加到列表中，另一个接受另一个列表并附加整个内容；但如果不使用第一个 append 方法填充我传入的列表，我就无法测试第二个 append 方法(需要整个列表的方法).我应该将这两种方法的单元测试相互分开吗?

I'm having trouble getting my unit tests to stay independent of each other. For instance, I have a linked list with two append methods, one that takes a single element and appends it to the list, and one that takes another list and appends the whole thing; but I can't test the second append method (the one that takes a whole list) without using the first append method to populate the list I'm passing in. How do I keep the unit tests for these two methods separate from each other?

推荐答案

您描述的情况在测试中无处不在:您有一些类或库要测试.类或库有一些需要测试的方法/函数，为了测试其中的一些，你必须调用同一个库的其他方法/函数.

The situation you describe happens everywhere in testing: You have some class or library to test. The class or library has certain methods / functions that need to be tested, and for the test of some of these, you have to call other methods / functions of that same library.

换句话说，当根据四阶段测试模式(设置、练习、评估、清理)分解测试时，你想在练习阶段调用你的类/库.但是，您必须在设置阶段以及可能在评估和/或清理阶段调用它的某些元素似乎很烦人.

In other words, when breaking down the test according to the four phase test pattern (setup, exercise, evaluate, cleanup), you want to call your class / lib in the exercise phase. However, it seems annoying that you have to call some elements of it also in the setup phase, and, possibly, also in the evaluate and/or cleanup phases.

这是不可避免的:您提到在列表 append 函数的设置中必须使用单元素 append 函数.但是，更糟糕的是:您还必须使用列表类的构造函数 - 没有它就没有机会逃脱.但是，构造函数也可能有问题...

This is simply unavoidable: You mentioned that in the setup for the list append function you had to use the single-element append function. But, it is even worse: You also had to use the constructor of your list class - no chance to get away without that one. But, the constructor could also be buggy...

肯定会发生的是，测试失败(或错误地通过)，因为设置中调用的函数有缺陷.然而，一个合适的测试套件应该(如评论中提到的)还对其他(称为低级)函数进行测试.

What can certainly happen is, that tests fail (or, mistakenly pass) because the functions called in the setup are defective. A proper test suite, however, should (as was mentioned in the comments) also have tests for the other (call them lower-level) functions.

例如，您应该有许多测试来检查您的类的构造函数是否正常工作.如果在某个时候修改了构造函数使其变得有缺陷，则在设置阶段使用构造函数的所有测试都不再值得信赖.但是，一些测试构造函数本身(因此在练习阶段调用它)的测试现在应该会失败.

For example, you should have a number of tests which check that the constructor of your class works correctly. If at some point you modify the constructor so it becomes defective, all tests that use the constructor in the setup phase are no longer trustworthy. But, some of the tests that test the constructor itself (and thus call it in the exercise phase) should fail now.

从测试结果的概述中，您将能够确定测试失败的根本原因.这需要对依赖项有一些了解:哪些测试侧重于较低级别的方面，哪些是较高级别的，因为它们依赖于某些较低级别的功能才能工作.

From the overview of the test results you will then be able to identify the root cause of the test failures. This requires some understanding about the dependencies: Which of the tests focus on the lower-level aspects and which are higher-level in the sense that they depend on some lower-level functionality to work.

有一些方法可以使这些依赖关系更加明显，从而使以后更容易分析测试失败 - 但这些都不是必需的:

There are some ways to make these dependencies more apparent and therefore make it easier to analyse test failures later - but none of these are essential:

• 在测试代码中，您将较低级别方面的测试放在文件顶部，将更多相关测试放在底部.然后，当几个测试失败时，首先查看最接近文件顶部的测试.请注意，测试代码中的测试顺序并不一定意味着执行顺序:例如，JUnit 并不关心测试方法在测试类中的编写顺序.
• 正如评论中所建议的，您还可以将测试框架配置为在其他测试之前运行较低级别的测试.

这篇关于保持单元测试分离和独立的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！