您在多大程度上单元测试功能？

Question

我对单元测试有疑问.我将使用一个例子来概述它.

假设我正在编写一个命令行应用程序,它具有各种可接受的命令,并且每个命令都有其可接受的参数.例如:myapp create -DprojectName = newProject -DprojectVersion = 1.0.

如果我有一个名为Command的类,它有一个validateArguments方法,它接收一个有效的参数名列表并将它与用户指定的参数列表进行比较,你将如何进行单元测试呢？

我看到的可能性是:

1. 您编写了两个单元测试 - 一个确保在传入有效参数时不会引发错误,另一个确保在传递无效参数时抛出错误.

2. 您编写了一个单元测试,确保不会拒绝所有可接受的参数.我最终会对每个可接受的参数进行单元测试:

   @Test public void validateArgments_ProjectNameArgPassed_NoExcepton thrown {...}

   @Test public void validateArguments_ProjectVersionArgPassed_NoException抛出{...}

等等.

对我来说,第一种方法是有道理的.但它并不能确保每一个应被接受的论点都是.

Answer 1

在不知道底层代码的逻辑的情况下很难建议(单元测试是白盒测试而不是黑盒子的原因)但我对该代码的处理方法是一系列单元测试,其中包含以下测试:

• 所有参数均无效
• 所有参数均有效
• 有效参数和无效参数的不同组合(用于测试上面未经测试的代码路径)
• 不同类型的无效参数,例如未指定,格式不正确(-projectVersion = Hippopotamus),值不正确(-projectVersion = 99.0)等.
• 我可能会想到的任何其他失败情况.

我发现单元测试的真正好处不在于测试成功场景,因为一些简单的集成测试也可以提供这样的好处.我发现真正的好处是测试了许多错误的场景,因为通常很少运行的代码(即错误处理)包含可能在未被注意的测试级别中滑过的错误.