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

前端之家收集整理的这篇文章主要介绍了单元测试 – 我应该对不应该在函数中传递的数据(无效输入)进行单元测试吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在尝试使用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上编写测试用例吗?

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

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

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

猜你在找的设计模式相关文章