如何对私有方法进行单元测试?(依据推荐等级排序)

前端之家收集整理的这篇文章主要介绍了如何对私有方法进行单元测试?(依据推荐等级排序)前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

如何对私有方法进行单元测试?(依据推荐等级排序

1. 不测试,没必要测试private方法。(但是1.c需要保证,或者参考TDD

a) 私有的方法一定是供暴露出来的方法调用的,测试了暴露方法,也就同时测试了私有方法,如果做不到,是否代码重构有问题?

b) 单元测试的目的是为了保证你修改复用代码时不会影响到所有引用这段代码的程序 private方法本来就不能被别的类引用,所以不需要用单元测试来保证其正确性。

c) 虽然不测试,但是是建立在以下原则上的,你不应该有任何方法是从一开始设计出来就是private的,因为你的每段程序都应该在单元测试的驱动之下产生,而测试是不可能驱动出来一个private方法的。那么private方法从哪里来?只能从重构而来。所以private方法是不需要测试的,因为它是重构的产物,而重构是不改变程序可观察之行为的。既然行为不改变,测试自然也不需要有任何改变,所以不需要针对private方法建立任何新的测试。

2. private方法变成protected或者package访问权限。

a) 个人其实不建议修改方法的作用域来迎合测试的需求,这样会暴露出不该暴露的实现细节,另外接口过多也破坏了SRP(单一职责原则)。其实只要保证了1.c可以看出也是没必要的。

b) 如果你认为private方法里有非常重要的业务逻辑,一定要测试。就可以用protected等修饰符来重新修饰这个方法的作用域。但是跟好的建议是:当你非常渴望测试一个private方法的时候,可以仔细评估这个private方法和目前所在类的关系,这样的private方法是不是应该迁移到另一个类中,在另一个类中作为public提供接口给调用方。

3. 在被测类中编写仅对测试有用的代码

a) 业务逻辑、测试代码混到一个类中,这是个很不好的建议,也不便于自动化测试管理。

4. 使用反射方式测。

a) 有点麻烦,个人不建议采用。

b) 你要测试的是对象的功能,而不是代码级别的方法。因为只有你暴露出来的功能才是给别的对象使用的。所以反射测试的意义不大。

2010-8-5

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