从极限编程中看“测试优先”

想必大家都体验过客户需求变更的痛苦，代码修改，删除，重写，无休止的加班，直到用户的需求不再变更。由此所见，需求的变更不仅会严重影响项目的日程，更给程序员带来痛苦。用户的需求变更不能避免，但是程序员如何最大避免需求变更带来的风险呢？在Kent Beck的推崇的极限编程(Extreme Programming, 以下简称XP)中，“测试优先”理念给我们提供了有效方法。

 

首先简单介绍一下XP。

XP，是有Kent Beck提出的，详细可以参考《Extreme Programming Explained》。

XP是程序设计工作上，以符合用户需要的软件为目标而产生的的方法论。它属于轻量级的方法，认为文档，架构不如直接编程带来的直接。

 

测试优先

从字面上我们就可以看出是什么意思，按照传统的开发模式，比如瀑布型的，从FD，DD，CD，UT，FT这样的顺序来开发，当有需求变更时，特别是在项目快要结束时，就从FD开始一次迭代，项目周期不得不的往后延长。这样的想法，其实潜意识里是把测试视为低优先权的工作。

测试优先，让程序员撰写程序之前先写好测试用例，或者是将测试式样书变成测试代码。这时肯定有人问，测试对象都没有，怎么把测试写好啊？其实，写完测试代码，是强迫要设计人员把类的接口定义清楚。写完测试代码后，也是编译一下，确定编写代码无编译错误后，将测试代码搁置。

此后，再将设计的类进行重构，重构的前提就是不能破坏测试用例，即不用修改测试代码。

写好的程序就可以马上进行测试了，java里的junit工具，c++的cppUnit工具，.net的NUnit工具，都可以帮我们轻松实现。测试后就可以进行修改，随时可以保证自己的代码质量。

若是此时发生了需求变更，测试通过的代码就可以重用。这样即使很大的变更，也会极大程度的降低修改工作。不过这里可是需要你的好的设计能力，让设计的类，高聚合低耦合啊。

 

好了，测试优先就介绍到这里吧，本人也在项目中具体实践过，受益匪浅，欢迎喜欢XP的朋友讨论，让XP给我们带来更大的收益。