前一段时间做了一些Android TDD（Test Driven Development）的工作。目前TDD好像还不是十分普及，因为它与传统上先写代码后测试的习惯有些相背，它是先写测试代码后写程序。其实要完成实现TDD是有一定困难的，想想吧，在写测试代码的时候就需要将程序的构造和逻辑都想清楚是十分困难的。但是，如果严格按照TDD的流程写出来的代码一般都会是高质量的，而且维护起来也简单得多。目前能想到的经验主要有以下几条，在以后的工作中如果还有新的经验会再添加。
1.慎用反射。程序中某些成员可能在测试代码中用得到，而程序中的成员却是私有的而且没有预留访问的方法接口。这时候可以适当地使用反射读取出这些成员的值用于测试，但是不可以使用反射修改这些成员的值，这样会破坏程序的完整性。在测试的覆盖率上或许会满足要求，但是仅仅是一种为了测试而测试，这显然与测试的目的是相左的。
2.测试要从用户的角度进行。这就是说测试时程序运行的流程要和用户使用这些程序时走的流程相同，这也是为什么不能使用反射直接为成员赋值的原因。一般说来，测试程序就是一个输入，然后判断一个输出是否同预期的值相同。
3.一般来讲，一个测试用例只测试一个点，否则在同一个测试用例里不同测试点可能会互相影响。
4.在每个测试用例运行前，都会调用setUp()方法。因此可以在这个方法里面做一些通用的准备工作。在每个测试用例运行结束后都会运行tearDown()方法，在这里面就是做一些扫尾的工作。这样就可以保证每个测试用例运行时其环境是干净的，各个测试用例之间互不影响。
5.慎用静态数组。在对service的测试中，发现其在第一个测试用例运行完毕调用的tearDown()中会将静态数组的内容的清空，这样如果后面的测试用例也用到这些静态数组就会产生空指针错误，不知道这是Android的一个bug还是其出于某些原因故意这么做的。但是在service以外的测试中是不是这样的还不清楚。
6.测试用例的代码要尽可能的简单可靠。测试代码是用来测试目标程序的，首先必须要保证测试代码的正确性，这是测试成功的前提，如果测试代码的可靠性不能确定，那么它的测试结果就不可靠了。一般来讲，测试代码要尽可能的简单，这样会减少出错的可能性，另外测试代码要尽可能多地使用系统的接口和方法，因为我们可以认为系统中的代码都是可靠的，可以作为一个标准来测试我们写的代码。
阅读(2471) | 评论(0) | 转发(0) |
