单元测试的噩梦

如果功能有重大调整了，你如何处理，有些并不一定是程序设计的问题，也有可能是企业政治，或者是其它的问题导致重构，我的项目现在已经进行了2次重大的调整，但是都是很有必要的。罗马不是一天建成的，最初的设计也不见得是完善的，你也不可能一点一点的思考，思考是跳跃性的，那么设计也会随着思考而跳跃，从而导致大规模的重构。另外我想关心的是，UI部分如果进行单元测试？包含UI组件的状态、事件，总是靠人工的浏览，点击？有没有更好地解决方案？

功能调整不是重构。请看Kent Beck的“两顶帽子”。

重构是在不改变功能的前提下进行的。

设计上的变化么？一点个人见解，刚刚思考得到的。
如果目的很明确还真必须这样，恐怕得从0开始，整体浏览测试用例，更改/删除相关部分，然后一点一点重构，一点一点测试，整个重构过程要所有相关的人都停下来做重构，大量沟通。
这种大规模变化确实要有几个能把握全局的经验丰富的硬手。至少确定重构和什么类相关就需要这种硬手。
xp高速迭代和轻装上阵使得早期的很多东西可能被人遗忘掉，如果在以前开发过程中沟通不够，可能要几个记忆力好的了，可能还得问问以前做这块的人。

唉，我也碰到这个问题。。。

嘘!"沟通不够"这句话在XP团队中是忌讳的,因为XP绝大多数原则的目标,就是加强成员之间的直接的沟通.
"早期的东西被忘掉"指的究竟是什么呢?如果是需求,那么没关系,最新的设计需求始终纪录在我们的单元测试中,客户需求有Story Card可以查.更早的?既然已经变化,那么记那么清楚,意义也就不大了.
如果你指的是设计本身,那么,代码就是设计.读代码吧.XP强调每个人都是代码的所有者,强调Pair Programming,那么项目进行了这么长时间,每个人都应当对多数的代码很熟悉了,至少每一个模块不应当只有一个人懂.为什么?Pair Programming,你听说过吗?
我并不是在说XP解决了所有的问题,而是说,它至少不比其他的开发方式在这些问题上处理上更困难.当然,附带的是你真的是XP了,而不是仅仅是说说而已.

功能有重大调整，是不是应该先重构测试代码？测试代码不单纯只是为了测试吧，应该包含了对需求的分析和验证。

实际上就我个人的感觉
仅仅只是单独的使用Unit Test作为一个bug检测器的作用话
实在是弱化了Unit Test可能带给你的好处
在我们这里
Unit Test 只是作为软件质量保证的一个关键
另外
1.code review
在适当的时候（需要项目管理者把握，反正我们的周期是两三天） 留出专门的时间对代码按照一定的原则和顺序 进行复查 用流行的词就是重构 。实际上我们完成的工作比重构这个词包含的还广泛一点
比如：若是在代码复查的时候发现 需求功能上不妥
我们会简单判断后 将及时可以解决的问题解决
（当然这样做 不是 Pure XX）

2.短时间
就是说 保证你进行创建和测试的时间 一次不要超过
1min最妙了
不然 就很不爽了
这需要对模块的细分 系统比较低的偶合度

还有就是 我说的体系的问题 质量保证千万千万千万
不要以为一个Unit Test就搞定了
不同的粒度
要用不同方法

十分钟跑一遍测试？请问你在开发中实践过吗？checkin时间，编译时间，运行单元测试时间，测试后大家交流时间，扯皮时间，这些加起来都有好几分钟，那你拿什么时间写代码呢？每十分钟的代码都能保证编译通过吗？
我觉得单元测试本来就不是个完美的东西，存在这样那样的问题，既然选择了做单元测试，就要接受一些它的弊端。维护单元测试代码，就需要花费成本。

我自己玩得一个非常小规模的程序(一个人写了6个月)，大概有80个测试类，250个测试方法，从重新购建到测试大概需要2分半钟(maven)，其中测试1分半。
我不知道哪种有意义的应用能够每10分钟把所有测试跑一边。