测试驱动开发实践

hexq

近来开发过程中接触了一个叫做测试驱动开发的东东，虽然说测试这个部分的工作是测试工程师的工作，但是作为一个程序员，学习测试驱动开发也是提高个人开发效率的一个办法。学校图书馆关于这方面的书籍少之又少，我找了一个下午才找到一本。测试驱动开发使用的工具：java使用的JUnit，其它开发语言也有对应的。JUnit在eclipse有带，如果使用其它开发工具的话就需要自己去下载咯。

先讲解一个实际的例子，给大家一个感性的认识，然后再讲解具体的理论。
例子:
我们要写一个MathUtil类的一个add方法，方法接口设计如下：
class MathUtil {
public static Object add(Object a, Object b);
}
要求能够处理以下情形：
a和b都是Integer类型
a和b都是String类型
不好的习惯:
Object add(Object a, Object b) {
return null;
}
这会留下隐患，除非你迫不得已，否则不要这样做。

测试驱动的方式:
首先构建一个方法，确定接口
Object add(Object a, Object b) {
throw new TODOException();
}

编写测试用例:
void testAdd() throws Exception {
Object left = new Integer(1);
Object right = new Integer(2);
Object result = MathUtil.add(left, right);
assertEqual(result, new Integer(3));
}

根据测试用例补充代码:
这时，testAdd的测试方法是运行不通过的，怎么处理呢？
答案很简单：根据测试用例的运行结果补充代码!

进一步完善-代码:
Object add(Object a, Object b) {
if (a instanceof Integer
&& b instanceof Integer) {
int leftVal = ((Integer)a).intValue();
int rightVal = ((Integer)b).intValue();
return new Integer(leftVal + rightVal);
}
throw new TODOException();
}

补充代码后的情况:
补充完上面的代码后，已经能够Integer相加的情况，我们可以通过这种方式继续补充测试用例和实现代码。
简单总结:
我们通过上面的例子看到，测试驱动的步骤是：
1、设计主要接口
2、编写测试代码
3、根据测试运行结果补充实现
循环2和3

注意点:
使用TODOException处理未完成的部分
在编写代码时，注意代码执行路径的全集
在测试代码中，使用assert
功能完成后，可能要进一步进行代码优化
测试驱动和单元测试的区别:
测试驱动：先设计主要接口，接着编写单元测试，根据测试结果补充代码实现
测试驱动是一个开发方法，而单元测试，只是一些对程序的测试代码，或者其它测试手段

为什么需要单元测试:
1、复杂的系统，你也许一时难以下手，无法全面构建，测试驱动，使得你能够从容设计，自顶而下。最初设计主要的接口，不管具体的实现。
2、这种开发方式，开发完成后，代码质量通常较好，而且很容易进行回归测试
复杂的例子怎么办？
答案是：没什么两样，例如：
String connString = "...";
IDbConnection conn = new SqlClientConnecion(connString);
conn.Open();
asertEquals(conn.State, ConnectionState.Open);
conn.close();
asertEquals(conn.State, ConnectionState.Close);
这个例子测试了Connection对象的状态转换。

powerwind

Good！
可惜Debug都少用，更不用说单元测试了。做项目的人就是不一样。

hexq

测试驱动开发入门比较慢。。。但是对一个爱好写程序的人有很好的帮助，希望大家都能去接触下，在平时自己课程设计中可以去应用

用程序诠释生命

　　握个手。我也曾经研究过测试驱动一段时间。不过我本身不太支持严格的测试驱动，开发效率会比较低，不过也可能是我没有真正理解测试驱动开发的原因。

　图书馆至少有五本测试驱动的书，在数据库的书旁边不远。（大学城）
　　
　　另外，我不觉得测试完全是测试工程师的事，单元测试应该是程序员做的工作。一方面可以检查你编的代码是否正确（单元测试是一个很快捷的测试是否正确的方法，而不用跟实际的UI结合，节省了时间），另一方面也可以展示一些程序的调用方法（我看源码首先看单元测试）。
　　

hexq

我是比较支持测试驱动的，虽然测试驱动是麻烦了点，想想写一个应用的时候要先写它的实例，的确是比较繁琐，但是从长远考虑，测试驱动并不会说开发效率低，因为按照写好了的实例一步一步去实现，写起来会事半功倍，而且对以后的代码维护也是有好处的。
anyway，我自己研究的还是不深入，只是在平时开发的时候，尽量去按照测试开发的方法来开发，