我们有一个约定来验证构造函数和公共函数/方法的所有参数.对于引用类型的强制参数,我们主要检查非null,这是构造函数中的主要验证,我们在其中设置了类型的强制依赖.
头号我们之所以这样做是为了赶上早错误,并没有得到一个空引用异常几个小时上下行不知道哪里引入错误参数或当.随着我们开始转向越来越多的TDD,一些团队成员认为验证是多余的.
作为TDD声音倡导者的Bob叔叔强烈建议不要进行参数验证.他的主要论点似乎是"我有一套单元测试,确保一切正常".
但我可以在它的生命中看不到单元测试可以阻止我们的开发人员在生产代码中使用错误参数调用这些方法的方式.
请单位测试人员,如果你能用合理的例子向我解释这个问题,我会非常乐意抓住这个参数验证!
我的回答是"它不能." 基本上听起来我不同意鲍勃叔叔(除此之外).
很容易想象你已经对库代码进行单元测试以获得非空参数的情况,并且你已经对你的调用代码进行了单元测试,以获得一个恰好为库提供null参数的路径而你不知道它,但也不会导致该特定路径的任何问题.您可以获得100%的覆盖率,实际上是一组非常好的测试,但仍然没有注意到问题.
一切都好吗？不,当然不是 - 因为你违反了图书馆合同(不要给我一个非空值)而不知道它.您是否觉得您提供空参数的唯一情况是无关紧要的？我不这么认为 - 特别是如果你甚至不知道论证是空的.
在我看来,无论调用代码和API本身是否经过单元测试,公共API都应验证其参数.调用代码中的问题应该暴露出来,并尽早公开.