|
锁定老帖子 主题：使用反射提高单元测试的质量
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-07-01
zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 不要空对空。拿例子出来说。 |
| 返回顶楼 | |
|
发表时间：2010-07-01
最后修改：2010-07-01
gigix 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 不要空对空。拿例子出来说。 设计非常混乱的代码发给QA时 QA常常不能明白某些方法存在的目的 并且这些方法的覆盖直接影响到QA的成绩单. 目的决定手段. |
| 返回顶楼 | |
|
发表时间：2010-07-01
gigix 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 不要空对空。拿例子出来说。 前边例子已经举过，真实的代码当然是公司的，不能外泄。但是抽象出的示例代码已经可以说明问题了。 |
| 返回顶楼 | |
|
发表时间：2010-07-01
抛出异常的爱 写道 gigix 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 不要空对空。拿例子出来说。 设计非常混乱的代码发给QA时 QA常常不能明白某些方法存在的目的 并且这些方法的覆盖直接影响到QA的成绩单. 目的决定手段. 这里讨论的测试是开发程序员的测试，是建立在对代码熟悉基础上的。 |
| 返回顶楼 | |
|
发表时间：2010-07-01
引用 private int getUserAge(String userId) 这种空对空的代码是没有任何意义的 |
| 返回顶楼 | |
|
发表时间：2010-07-02
太多的private说明此类承担太多责任或者过于复杂，无论怎样，说明抽象程度不够，拆分不够，所以测试难以覆盖，才会想到用反射来做测试。
所以测试多好，一下就帮你发现问题了。。 |
| 返回顶楼 | |
|
发表时间：2010-07-02
zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 一个复杂到要单独测试的private方法,要考虑它所承担的职责,不是简单的提取作为帮助类. 内聚性不是设计复杂的多职责类的借口. |
| 返回顶楼 | |
|
发表时间：2010-07-03
scott.yao 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 一个复杂到要单独测试的private方法,要考虑它所承担的职责,不是简单的提取作为帮助类. 内聚性不是设计复杂的多职责类的借口. 不是多职责类，而是本身的业务就是很复杂。 |
| 返回顶楼 | |
|
发表时间：2010-07-07
zhang_xzhi_xjtu 写道 scott.yao 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 一个复杂到要单独测试的private方法,要考虑它所承担的职责,不是简单的提取作为帮助类. 内聚性不是设计复杂的多职责类的借口. 不是多职责类，而是本身的业务就是很复杂。 没有任何类是生来就有理由复杂的，如果业务的确很复杂，请考虑将这些复杂的业务拆分清洗，然后分解到若干个功能简单清洗的类上去。不必介意小类的出现，不必介意类数量的增加。 实现同样的功能，1个复杂的类肯定比10个清晰短小的类要“复杂”。 |
| 返回顶楼 | |
|
发表时间：2010-07-09
skydream 写道 zhang_xzhi_xjtu 写道 scott.yao 写道 zhang_xzhi_xjtu 写道 gigix 写道 不要测试private方法
如果private方法复杂到了需要被单独测试的程度，你需要把它抽取成一个单独的类 这种办法我也想过，问题是， 抽象成一个单独的类，也不过是只要让原来那个类调用，那么这个类只是一个帮助类，同时，同时，如果按照这种方法，有可能有大量的方法定义在这个帮助类中，方法的访问属性又变成了高于private的。如果高于private，那么还不如在原有的类中放宽方法的访问限制，那样还可以提高类的内聚性。 一个复杂到要单独测试的private方法,要考虑它所承担的职责,不是简单的提取作为帮助类. 内聚性不是设计复杂的多职责类的借口. 不是多职责类，而是本身的业务就是很复杂。 没有任何类是生来就有理由复杂的，如果业务的确很复杂，请考虑将这些复杂的业务拆分清洗，然后分解到若干个功能简单清洗的类上去。不必介意小类的出现，不必介意类数量的增加。 实现同样的功能，1个复杂的类肯定比10个清晰短小的类要“复杂”。 这个我是完全同意的。 但是这里讨论的是测试问题，即使分拆成多个类，还是没有解决如何测试的问题。 公开了这些小类的方法，不太符合设计的内聚性。 私有话了这些小类的方法，就不好测试。 |
| 返回顶楼 | |
