【开发】测试驱动的FLEX开发--使用FLEXUNIT

http://elromdesign.com/blog/2010/03/10/test-driven-development-tdd-with-flexunit-4-complete-tutorial/

本来是打算完整的翻译完成这篇博文的，一边翻译，一边谈谈自己对驱动测试开发的理解。 当然我的理解和原文作者的理解不一定一样，但是至少，我们都承认开发得是测试驱动的。 然而CSDN的博客系统是实在不能理解【无法大篇幅的CP过来】， 那我就引用一下这篇文章。 稍微谈一下我对测试驱动的开发的理解。

 

这篇文章无疑是很值得一看的，而且带有详细的例子演示了测试驱动的开发。 在FLEX这样一个界面侧重的框架中，测试驱动更是必不可少的。其实要看懂这篇文章并不困难，熟悉FLEX的人可能都不屑于看这种TUTORIAL，我觉得引这篇文章的主要目的是强调测试驱动开发的重要性，特别是在FLEX这样的框架下面。

 

传统的软件过程中，测试是独立于开发部分的，（我还是乐于讨论软件工程的东西），开发者完成开发后交给测试者进行测试，发现问题，开发者修改，然后再测试。 似乎是没有问题的，问题就在于代价，这样的一次改动带来的时间消耗是可观的，特别是在需求变动频繁的情况下。之所以强调测试驱动的开发在FLEX下的情况，就是这个道理，FLEX是偏向于客户端，偏向于界面的东西。 而外观是整个软件系统中最容易发生变化的部分，每个人对界面的定义都是不同的，因此在项目的迭代过程中会带来大量的界面更改的需要，这些界面如果耦合着业务逻辑，而且没有测试代码的话，这种修改代价可以想象，你永远无法知道系统中到底是不是还有隐藏的bug，你永远不知道某个变更的需求到底是不是在不影响原有业务逻辑的情况下完成了。

 

强调测试驱动开发的好处之一就是避免这样的情况，开发者在编写程序的过程中就已经随手写好了所有代码的测试，那么任何改动，只需要将原来的测试执行一遍，便能够确认改动是不是在预期内达到要求了。 另外一个附加的好处就是能够让开发者能够有更多的时间来整理思路，考虑整个项目的架构设计问题， 通常情况下开发者总是拿到需求然后就开始编码，只管把当前的任务完成了就算，然而如果不对问题进行整体考虑，短期内似乎需求是满足了， 但是一旦发生需求变更，可能这次的修改还得重新再实现一次。 测试驱动的开发就是要把这种情况出现的概率尽可能的降低。 测试驱动的开发要求开发者将软件中相对独立的过程解耦出来便于测试， 因为与界面设计耦合的业务逻辑是无法测试的。

 

通常情况下，初级的开发者总是认为函数的产生是随意的，写到一行，恩，这里需要一个函数，好那就写个函数，至于函数的参数，函数的命名，返回类型都是随心所欲，能完成手头的事情就可以。 然而这些天然形成的开发习惯 对于需求变动频繁的开发无疑是很大的错误。 在这样的情况下可能出现的情况就是后期的变更将引起前期已经完成的变更重新走入变更程序， 而原因就在于当初变更发生的时候，没有能够正确认识到后期仍然可能存在的变更。 从另一个角度来说，测试驱动的开发将有助于开发者的成长， 因为关注点从编码到整个架构的完善，无疑是很大的飞跃。

 

然而我并不是说所有的人都关注架构了，变更就不存在问题了， 可以借用上面的观点，这样来说：当开发者的水平提升了，那么变更就容易处理了。 开始尝试测试驱动的开发，在我看来无疑是提升自己的开始。