1)什么样的步伐合适:测试(对应一行代码清单和少数重构);刚开始重构要严格遵循步骤,当然也不放过自动化重构工具
2)什么可以不必测试:如果不含业务逻辑,如jsp页面只是显示,业务重点测试(条件部分,循环部分,操作部分,多态性)
3)怎样知道代码有缺点:
1.编写测试,创建的对象数据设置代码很长(对象太大,需要分割)
2.冗余的设置代码(如果公共设置代码找不到存放场所,则对象过于耦合)
3.过长的测试运行时间(设计问题)
4.脆弱的测试(测试之间彼此影响,独立性差,要么将影响的部分合并,要么解耦)
4)测试驱动开发怎样引领框架的产生:当实现第二个功能时是第一个功能的变种。将重复的代码放在同一地方,不同的代码放在不同的方法或类。继续下去,则重复部分会越来越抽象和稳定。
5)编写多少测试:根据实际需要
6)什么时候不删除冗余测试:当删除测试影响你的自信和与读者沟通时。
7)中途转向测试开发:限定修改的范围,打破测试和重构之间的僵局(系统级别的测试)
8)测试驱动和模式的关系:最好是只考虑你希望系统完成的功能,让好的设计自己“浮出水面”。
原文链接:https://www.f2er.com/javaschema/286606.html