我应该如何对具有许多子功能的功能进行单元测试? [英] How should I unit test functions with many subfunctions?

问题描述

我希望更好地理解我应该测试具有许多子步骤或子函数的函数.

I'm looking to better understand I should test functions that have many substeps or subfunctions.

假设我有这些功能

// Modify the state of class somehow
public void DoSomething(){
    DoSomethingA();
    DoSomethingB();
    DoSomethingC();
}

这里的每个函数都是公开的.每个子功能有 2 条路径.因此，要测试 DoSomething() 的每条路径，我需要进行 2*2*2 = 8 次测试.通过为 DoSomething() 编写 8 个测试，我也间接测试了子函数.

Every function here is public. Each subfunction has 2 paths. So to test every path for DoSomething() I'd have 2*2*2 = 8 tests. By writing 8 tests for DoSomething() I will have indirectly tested the subfunctions too.

那么我应该像这样进行测试，还是应该为每个子功能编写单元测试，然后只编写 1 个测试用例来测量 DoSomething() 之后类的最终状态并忽略所有可能的路径?总共 2+2+2+1 = 7 次测试.但是，DoSomething() 测试用例将依赖于其他单元测试用例来实现完整覆盖是不是很糟糕?

So should I be testing like this, or instead write unit tests for each of the subfunctions and then only write 1 test case that measures the final state of the class after DoSomething() and ignore all the possible paths? A total of 2+2+2+1 = 7 tests. But is it bad then that the DoSomething() test case will depend on the other unit test cases to have complete coverage?

推荐答案

似乎有一种非常普遍的宗教 信念，即测试应该是单元测试.虽然我不打算低估单元测试的用处，但我想指出它只是一种可能的测试风格，它的广泛(甚至独家)使用表明人们(或环境)有些不安全关于他们在做什么.

There appears to be a very prevalent religious belief that testing should be unit testing. While I do not intend to underestimate the usefulness of unit testing, I would like to point out that it is just one possible flavor of testing, and its extensive (or even exclusive) use is indicative of people (or environments) that are somewhat insecure about what they are doing.

根据我的经验，系统内部工作原理的知识作为测试的提示很有用，但不能作为测试的工具.因此，在大多数情况下，黑盒测试要有用得多，尽管无可否认，部分原因是我对自己正在做的事情没有安全感.(这反过来又是因为我广泛地使用断言，所以基本上我的所有代码都在不断地自我测试.)

In my experience knowledge of the inner workings of a system is useful as a hint for testing, but not as an instrument for testing. Therefore, black box testing is far more useful in most cases, though that's admittedly in part because I do not happen to be insecure about what I am doing. (And that is in turn because I use assertions extensively, so essentially all of my code is constantly testing itself.)

在不知道您的案例的具体情况的情况下，我会说一般来说，DoSomething() 通过调用 DoSomethingA() 然后DoSomethingB 来工作的事实() 然后 DoSomethingC() 是你的黑盒测试最好不知道的实现细节.所以，我肯定不会测试 DoSomething() 调用 DoSomethingA(), DoSomethingB() 和 DoSomethingC()，我只会测试以确保它返回正确的结果，并使用它实际上调用这三个函数的知识作为我将实现的提示正是您计划使用的 7 个测试.

Without knowing the specifics of your case, I would say that in general, the fact that DoSomething() works by invoking DoSomethingA() and then DoSomethingB() and then DoSomethingC() is an implementation detail that your black-box test should best be unaware of. So, I would definitely not test that DoSomething() invokes DoSomethingA(), DoSomethingB(), and DoSomethingC(), I would only test to make sure that it returns the right results, and using the knowledge that it does in fact invoke those three functions as a hint I would implement precisely those 7 tests that you were planning to use.

另一方面要注意，如果DoSomethingA()和DoSomethingB()和DoSomethingC()是还有公共函数，那么你也应该也单独测试它们.

On the other hand, it should be noted that if DoSomethingA() and DoSomethingB() and DoSomethingC() are also public functions, then you should also test them individually, too.

这篇关于我应该如何对具有许多子功能的功能进行单元测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！