我应该对不应该在函数中传递的数据(无效输入)进行单元测试吗？

Question

我正在尝试使用TDD进行编码练习.我想问一下,我应该测试一个不应该在函数中发生的数据,但这些数据可能会破坏你的程序.

这是一个简单的例子来说明我的要求:

具有一个INT参数的ROBOT函数.在这个函数中我知道有效范围只有0-100.如果使用-1,101,则该函数将被中断.

function ROBOT (int num){
...
...
...
return result;
}

所以我决定了这个功能的一些自动化测试用例......

1. function ROBOT with input argument 0
2. function ROBOT with input argument 1
3. function ROBOT with input argument 10
4. function ROBOT with input argument 100

但是我应该为这个ROBOT函数编写带输入参数-1或101的测试用例如果我在我的其他函数中保护那个调用函数ROBOT ???

5. function ROBOT with input argument -1
6. function ROBOT with input argument 101

我不知道是否有必要因为我认为测试-1和101是冗余的.如果真的有必要覆盖所有情况,我必须编写更多代码来保护-1和101.

那么在TDD的通用实践中,你会在-1和101上编写测试用例吗？

Answer 1

是的,你应该测试那些无效的输入.但是,如果您的语言具有可访问性修饰符并且ROBOT()是私有的,则您不应该对其进行测试; 你应该只测试公共功能/方法.

功能测试技术称为边界值分析.

如果你的范围是0-100,你的边界值是0和100.你应该测试,至少:

• 低于边界值
• 边界值
• 高于边界值

在这种情况下:

1,0,1,
99100101

假设-1到-infinity以下的所有内容都表现相同,1-99之间的所有内容都表现相同,而101以上的所有内容都表现相同.这称为等价分区.边界值之外和之间的范围称为分区,您可以假设它们具有相同的行为.

您应该始终考虑使用-1作为测试用例,以确保如果参数不是强类型,则负数和文本字符串不会发生任何有趣的事情.

Answer 2

如果预期的结果是抛出了带有无效输入值的异常,则适当抛出异常的测试将是合适的.

编辑:

正如我在下面的评论中所指出的,如果这些案例会破坏您的申请,您应该抛出异常.如果这些情况在逻辑上确实不可能发生,那么我会说不,你不需要抛出异常,而且你不需要测试用例来覆盖它.

请注意,如果你的系统以及组件化的,而这个功能是一个组成部分,事实上,它是逻辑上是不可能现在并不意味着它永远是逻辑上是不可能.它可能会在不同的道路上使用.

Answer 3

您说如果参数无效,您的方法将引发异常.

所以,是的,你应该,因为你应该测试引发异常.

Answer 4

简而言之,如果它可以破坏,那么你应该测试它.也尽可能早地验证数据.

答案取决于您是否控制传递给Robot的输入.如果Robot是内部类(C#); 值只从RobotClientX流入,这是一个公共类型.然后我将看守检查放在RobotClientX中,为它编写测试.我不会为Robot编写测试,因为无效值无法实现.例如,如果我将我的验证放在GUI中,以便在源处过滤掉所有无效值,那么我不会在GUI下面的所有类中检查无效值(除非我还公开了绕过GUI的公共API) ).

另一方面,如果机器人是公开可见的,即任何人都可以使用他们喜欢的任何值调用机器人,那么我需要测试来记录给定特定类型的输入的行为.无效是其中之一.例如,如果传递超出范围的值,则会抛出ArgumentException.