如何对特定的实现进行单元测试

问题描述 投票:0回答:2

我阅读了很多关于(单元)测试的信息,并且我尝试在日常工作流程中尽可能多地实施,但是以某种方式我感觉自己做错了。

假设我有一个函数,该函数采用一个路径,并根据该路径的某些元素为新的日志文件创建一个名称。路径可能是C:/my_project/dir_1/message01,应将其转换为dir_1_log_01.txt。函数的名称为convertPathToLogfileName

如果我想为此功能编写单元测试,它可能看起来像:

def test_convertPathToLogfileName():   
    path = "C:/my_project/dir_1/message01"

    expected = "dir_1_log_01.txt"
    actual = convertPathToLogFileName(path)

    assertEqual(expected, actual)

现在,我可以编写一堆这样的测试来检查所有不同种类的输入(如果输出是我期望的那样。

但是如果我决定我选择的日志文件的命名约定不再是我想要的东西了:我将更改功能以使其满足我的新要求,而所有测试将失败。

这只是一个简单的例子,但我经常是这种情况。在编程时,我想出了一种新的方法来进行测试,然后我的测试失败了。

这里是否缺少我所要测试的东西?如果是这样,您将如何处理这种情况?还是这就是现状,我应该接受吗?

unit-testing testing tdd software-design software-quality
2个回答
0
投票

这里是否缺少我所要测试的东西?如果是这样,您将如何处理这种情况?还是这就是现状,我应该接受吗?

不是。这是经典的“传入X导致输出Y”的情况。

您可以可能更改的一件事:也许之后,您已经完成了TDD,并且获得了各种小测试,这些小测试都可以验证被测函数的入/出契约的不同方面。 ..您可以将其拉入桌子。

含义:这里很可能不需要20种不同的测试方法(所有方法都相同)。为什么不使用包含成对的“ X in”的简单列表应导致“ Y out”数据点。然后您有一个测试可以遍历该列表并测试这些对。

但是回到您的主要问题:您不是在测试实现。您的测试only进行黑盒进/出测试:X进入,Y希望出现。

换句话说:您的测试将验证合同,而不是实施实现以某种方式>>为即将到来的特定X计算正确的Y的代码。无论您的“生产用户”还是测试用例,完成操作的方式都无关紧要!

因此:如果您的合同曾经(完全)更改过,那么您当前的所有测试都将变为无效。是的,当您遵循TDD时,这可能意味着您(或多或少)从头开始。


0
投票

我在这里缺少什么吗?

© www.soinside.com 2019 - 2024. All rights reserved.