单元测试与重构

[nivaini]

对于单元测试，如果按照书上所说：

1.单元测试与功能测试不同，是对各个组件的独立测试
2.单元测试为重构起到安全网的作用
3.单元测试减轻了设计的压力，可以先进行简单设计，然后逐渐重构出成熟的设计

那么:
我如果对这些组件的设计进行重构的话，那么单元测试也需要跟着变，那岂不是起不到“安全网”的作用了？那么最终我还是不敢轻易对设计进行重构。难道单元测试只是针对接口固定，极小范围的重构有用处？

比如你针对类A写了一些单元测试，但重构以后可能A这个类都不存在了，这些单元测试也都得重写，那这些测试还有什么意义呢

在下愚钝，百思不得其解，看了好多书，论坛也翻遍了，还是没有找出这个问题的答案，无奈发帖来问。

[nivaini]

to:ericzhangali
“不改变行为”就代表不改变设计吗？，如果重构是建立在不改变设计前提下，那重构的范围也太小了，什么“提炼类”、“搬移函数”之类的常用的重构手法都无法使用。
那么我还是要在编码前用大量时间进行详细设计，否则我的单元测试就会经常改变，请问这怎么解释？

to:microtry
谢谢你的热心，但你的观点：
“
一个组件既然通过了测试,就不会再去改动了,
除非发现新的BUG,那么为了解决BUG,需要的是"重写",而不是重构,
CPU一直飞速的更新换代,你见过把做好的CPU收回"修改"的吗?那种复杂的产品想改都难,
”
这好像与martin fowler和kent back他们的敏捷思想相差很远，更接近于传统的瀑布模型吧，似乎你的“重构”与他们说的的重构根本不是一件事情。

[loveisbug]

不改变行为不代表不改变设计。
如果你在编码前不用大量时间进行详细设计，那你活该经常改变单元测试。

[nivaini]

好吧，我活该，你的意思是不迭代？一斧子搞定设计？那么，编码前用大量时间进行详细设计，这还是敏捷吗？

[loveisbug]

没说一点不改变设计，
改变设计可能会改变单元测试，
如果单元测试的改变频繁到不能接受，
那就是设计没有做好，
要么就是接受，
要么就是不去动它了。

[缪军]

楼主,其实我更喜欢"极限编程"和"灵巧编程",这样的名字更能给我灵感,马丁福勒的很多观点我也很欣赏,
关键还是怎么理解人家的思想,比如我摘录了一段马丁的原文:
The software industry has a delight in taking words and stretching them into a myriad of subtly contradictory meanings.
他们在贴出代码的时候比较随意,因为代码都有较强的背景和针对性,那其实只是例子,
他们在表达观点的时候却小心翼翼,你很少看到明确简单的定义,这一点马丁本人在他的著文中不止一次提及,
我更加注意的是原著中流露出来的理论观点,而不是代码,
作者真正的思想往往藏在不起眼的地方表露出来,比如前言,序,概述,代码间隙,后记

很多读者怀着速成的心理,无视别人的背景,目标以及生产手段,无缘无故的去照搬所谓模式或代码,结果可想而知

[缪军]

我已经说过,重构不是Coder的事,是架构师的事,这是我的观点,
重构需求确定之后,设计文档就应该有能力生成测试,
根本就不存在你们讨论的改变不改变的问题,
换句话说
1.接口改变,测试随之改变;
2.测试也是可重用的,并且比受测代码更加容易重用;

[nivaini]

to ericzhangali:
“如果单元测试的改变频繁到不能接受，那就是设计没有做好”
如果已经设计得很好了，我还要重构干嘛？
如果我设计的不好的话，就只能接受了，不能重构了。
这不矛盾吗？
重构不是“改善既有代码的设计吗”？



to:microtry
你的意思是说,代码写好之后，就不能改变，如需改变，就要开发二期、三期、四期？之前的代码一点不能变，只能借来参考，用于提炼新的类库？
还有你说“测试也是可重用的,并且比受测代码更加容易重用”，能否简单解释一下，什么是“测试的类库”？测试如何重用？

[loveisbug]

重构是对软件内部结构的一种调整，目的是在不改变软件之可察行为前提下，提高其可理解性，降低其修改成本。
不改变行为，单元测试当然不变。
如果需要改变行为，单元测试也要变。这也没什么问题。

http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html

[缪军]

1.重构也是开发工序,当然要有测试,只是凑巧你可能利用到原先的测试,
其实真正测试工序是有类库的,也就是说测试种类也就那么几种,不需要经常增加新的测试;
2."可以先进行简单设计，然后逐渐重构出成熟的设计"
你可能理解错了,那不是针对项目而言的,
一个组件既然通过了测试,就不会再去改动了,
除非发现新的BUG,那么为了解决BUG,需要的是"重写",而不是重构,
如果需求变更会导致重新开发,那么请重新派工,这是新的开发任务了,
Coder的职责是在派工单规定的工时内通过测试,他不需要(也不应该)考虑"重构"这样的问题,
3.真正的重构是架构师回顾已有的项目,梳理其中的业务,如果发现有重用价值的,
会整理出新的设计来增强开发组织的架构或者类库,这和原来做好的那些个项目没有什么关系

[缪军]

[Quote=引用 1 楼 ericzhangali 的回复:]
重构是对软件内部结构的一种调整，目的是在不改变软件之可察行为前提下，提高其可理解性，降低其修改成本。
不改变行为，单元测试当然不变。
如果需要改变行为，单元测试也要变。这也没什么问题。

http://www.cnblogs.com/blueclue/archive/2010/06/01/1749308.html
[/Quote]

恰恰相反,重构跟项目无关,根本不会,也不允许改动已有的软件工程,
另一方面,业务功能很可能变化,而且重构是新的开发工作,测试当然与原先的测试没有必然联系

[缪军]

想想已经经历了200年的传统工业,或者哪怕是伴随软件技术一同发展的IT制造业,
CPU一直飞速的更新换代,你见过把做好的CPU收回"修改"的吗?那种复杂的产品想改都难,
新制程的出现不会应用在已经发布的产品上
,但是即使是将要生产的"老架构"的产品也可以从中获益,

我们整天把"面向修改封闭"挂在嘴上,但是我们却没有用到生产实践中

[缪军]

[Quote=引用 11 楼 nivaini 的回复:]
重构不是“改善既有代码的设计吗”？
to:microtry
之前的代码一点不能变，只能借来参考，用于提炼新的类库？
测试如何重用？
[/Quote]

楼主,improve design,而不是modify code,当理论应用到软件生产的实际过程的时候,
重构的定义就是:可以(不是只能)通过既有代码的设计的改进,(目的是)改进软件的设计能力和生产手段,
测试可以重用,这需要架构师或者设计师具备这样的能力:
1.架构能在运行时组装代码,而不是依靠代码生成器技术;
2.反射技术;
3.项目文档已经成为架构驱动核心(文档始终是最新的,领先于代码),不再是普通的word或excel,
4.所以测试工程始终能过通过读取文当动态的组装运行测试功能,并通过反射测试它假想已经存在的受测对象，任何时候都可以历遍文档运行测试

应该说:如果软件代码的重用问题是首先被解决的,当你的项目开发高度自动化的时候,这种自动化的经验很快就会应用到测试技术,这是自然而然的,一点都不牵强,
在这之前,所谓的测试驱动是效率低下的,这一点必须承认,
考察所有的工业生产线进化过程,你会发现,生产自动化越高,测试手段才越先进

再次强调,不要无视自己团队的人文背景、业务领域、技术条件和生产手段,生搬硬套别人的参考文献中的例子和方案

[缪军]

顺便说一下,很多人动辄就会提到马丁的大作,
可是当我不止一次的引用书中的原文和观点的时候,
他们却说:这明显与书中的相去甚远吗!

看来,我还要作电子版书摘,以方便大家交流的时候,可以随时引用

[黑泡泡选手]

如果是需求确定的情况下，代码重构，应该不会影响单元测试吧？只是代码结构设计的问题嘛！测试先行策略，你所谓的设计，是哪种设计？一般来说测试框架建立好了，实现代码也成型了！若是你初始的需求变化了，那单元测试也得随之变化呀！

[nivaini]

就目前大家的讲解看来，敏捷开发还是需要一个前提，就是需要有相对稳定的接口，如果这个接口没设计好，那对后边的单元测试和重构影响还是非常大的。
感觉microtry的方法还是比较超前，以我目前的水平还无法完全理解，呵呵。。。结贴！