软件开发方法的探索[2]

昨天夜里做梦又被”重构，重构”声中醒了，这是我从事IT行业以来体会最深的一个词语了。太富有内涵和伟大思想了。

上篇大概提到了敏捷开发中的一些内容，这回聊聊测试驱动开发和目前工作中如何推广这些技术的一些感想。

测试驱动开发，其道理很简单，即在编写程序乃至设计程序的时候，先想着如何写测试程序…确实很难转过弯来。尤其是在UI方面的测试大多数都是直观看的情况下，或者涉及到并发，网络，多线程编程的情况下，很少能有用到测试的（恕我孤陋寡闻！）。我在看完kent beck的测试驱动开发后，体会到一个东东----》针对我这种菜鸟级别的人来说：

1 测试程序应该是类似单元测试一样的东西。之前觉得测试驱动开发不可行的原因是老想着在代码已经完成的情况下再去编写针对整个系统的测试，当然是不可能的！！但是大系统必然都会分解成小单元，甚至包，类。针对这些类，包去编写单元测试是可行的，而且会带来很好的结果。例如最近编写了一个NetEngine类和一个XMLCodecFactory类，就完全可以针对这两个类单独搞一套testcase。这样的好处是就是如果以后谁维护或者谁重构的话，都需要先通过测试才可以提交代码。----扯远点了，这就是面向接口编码的好处，外部程序大量使用接口，这样可以有效得解除应用程序或模块之间的耦合。

2 测试程序要利用好现有的框架。目前最好的就是XUnit框架了。

在目前的公司，需求变化很大，定制化开发的东西很多，尤其是BSP一变化，经常出现从系统底层一直到应用层的变化，找bug！所以，姑且不谈测试驱动开发中的开发，我现在需要一种手段保证底层的变化不会扩散蔓延到上层来。所以必须针对底层模块编写CTS似的单元测试程序。我发现这个东西的最早是在使用android中的camera部分，里边有个测试程序。完全不用在java层编写，就是针对c++层和驱动层的测试。至少要保证这个是对的，我才能和才敢拿到应用层中去使用。

测试驱动开发对开发人员的技术素养和开发技巧以及思维有很大的挑战，目前看来我们公司是不太适合用测试来驱动开发，但是编写单元测试是有其重要的必要的。

例如，针对camera编写，针对mediaplayer编写，针对mediaScanner编写，针对FM编写等。

实际上，google的CTS就是为了解决这个问题而存在的，我们一定要理解它背后的苦衷！！