单元测试与复建

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

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

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

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

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

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

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

引用:

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

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

恰恰相反,重构跟项目无关,根本不会,也不允许改动已有的软件工程,
另一方面,业务功能很可能变化,而且重构是新的开发工作,测试当然与原先的测试没有必然联系
[解决办法]
想想已经经历了200年的传统工业,或者哪怕是伴随软件技术一同发展的IT制造业,
CPU一直飞速的更新换代,你见过把做好的CPU收回"修改"的吗?那种复杂的产品想改都难,
新制程的出现不会应用在已经发布的产品上
,但是即使是将要生产的"老架构"的产品也可以从中获益,

我们整天把"面向修改封闭"挂在嘴上,但是我们却没有用到生产实践中
[解决办法]
不改变行为不代表不改变设计。
如果你在编码前不用大量时间进行详细设计，那你活该经常改变单元测试。

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

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

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

引用:

重构不是“改善既有代码的设计吗”？
to:microtry
之前的代码一点不能变，只能借来参考，用于提炼新的类库？
测试如何重用？

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

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

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

查看更多 下一篇