您当前的位置:
单元测试与重构
对于单元测试，如果按照书上所说：
1.单元测试与功能测试不同，是对各个组件的独立测试
2.单元测试为重构起到安全网的作用
3.单元测试减轻了设计的压力，可以先进行简单设计，然后逐渐重构出成熟的设计
那么:
我如果对这些组件的设计进行重构的话，那么单元测试也需要跟着变，那岂不是起不到“安全网”的作用了？那么最终我还是不敢轻易对设计进行重构。难道单元测试只是针对接口固定，极小范围的重构有用处？
比如你针对类A写了一些单元测试，但重构以后可能A这个类都不存在了，这些单元测试也都得重写，那这些测试还有什么意义呢
在下愚钝，百思不得其解，看了好多书，论坛也翻遍了，还是没有找出这个问题的答案，无奈发帖来问。
------解决方案--------------------
重构是对软件内部结构的一种调整，目的是在不改变软件之可察行为前提下，提高其可理解性，降低其修改成本。
不改变行为，单元测试当然不变。
如果需要改变行为，单元测试也要变。这也没什么问题。
http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html
------解决方案--------------------
1.重构也是开发工序,当然要有测试,只是凑巧你可能利用到原先的测试,
其实真正测试工序是有类库的,也就是说测试种类也就那么几种,不需要经常增加新的测试;
2."可以先进行简单设计，然后逐渐重构出成熟的设计"
你可能理解错了,那不是针对项目而言的,
一个组件既然通过了测试,就不会再去改动了,
除非发现新的BUG,那么为了解决BUG,需要的是"重写",而不是重构,
如果需求变更会导致重新开发,那么请重新派工,这是新的开发任务了,
Coder的职责是在派工单规定的工时内通过测试,他不需要(也不应该)考虑"重构"这样的问题,
3.真正的重构是架构师回顾已有的项目,梳理其中的业务,如果发现有重用价值的,
会整理出新的设计来增强开发组织的架构或者类库,这和原来做好的那些个项目没有什么关系
------解决方案--------------------
------解决方案--------------------
想想已经经历了200年的传统工业,或者哪怕是伴随软件技术一同发展的IT制造业,
CPU一直飞速的更新换代,你见过把做好的CPU收回"修改"的吗?那种复杂的产品想改都难,
新制程的出现不会应用在已经发布的产品上
,但是即使是将要生产的"老架构"的产品也可以从中获益,
我们整天把"面向修改封闭"挂在嘴上,但是我们却没有用到生产实践中
------解决方案--------------------
不改变行为不代表不改变设计。
如果你在编码前不用大量时间进行详细设计，那你活该经常改变单元测试。
------解决方案--------------------
没说一点不改变设计，
改变设计可能会改变单元测试，
如果单元测试的改变频繁到不能接受，
那就是设计没有做好，
要么就是接受，
要么就是不去动它了。
------解决方案--------------------
楼主,其实我更喜欢"极限编程"和"灵巧编程",这样的名字更能给我灵感,马丁福勒的很多观点我也很欣赏,
关键还是怎么理解人家的思想,比如我摘录了一段马丁的原文:
The software industry has a delight in taking words and stretching them into a myriad of subtly contradictory meanings.
他们在贴出代码的时候比较随意,因为代码都有较强的背景和针对性,那其实只是例子,
他们在表达观点的时候却小心翼翼,你很少看到明确简单的定义,这一点马丁本人在他的著文中不止一次提及,
我更加注意的是原著中流露出来的理论观点,而不是代码,
作者真正的思想往往藏在不起眼的地方表露出来,比如前言,序,概述,代码间隙,后记
很多读者怀着速成的心理,无视别人的背景,目标以及生产手段,无缘无故的去照搬所谓模式或代码,结果可想而知
------解决方案--------------------
如果是需求确定的情况下，代码重构，应该不会影响单元测试吧？只是代码结构设计的问题嘛！测试先行策略，你所谓的设计，是哪种设计？一般来说测试框架建立好了，实现代码也成型了！若是你初始的需求变化了，那单元测试也得随之变化呀！
------解决方案--------------------