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