写可测试的代码

这两天在琢磨如何写测试代码。有点感触，在这里慢慢整理出来：

Mock。mock的英文意思是模仿、虚假，在软件测试里面，它代表一种测试手段和思路。跟同事请教了mock的基本用途和使用方法之后，我就觉得把mock描述为一种测试策略更准确点（我也没有系统的学习过测试相关理论，这里也是怎么想怎么说）。EasyMock这样的类库，就是这种策略的一个实现。说明这一点是因为第一次听到另外一个同事介绍Mock时把它解释为一个东西，我了解之后，我觉得不是东西，是模拟被测试类的依赖者而达到测试的目的的一种方法。

对于抽象类，不用单独去测试。实际上也没法测试。直接去测试它的inheritors就可以了。

每个程序员都要明白测试的技术，才能写出可测试的代码。我今天自己给自己前两天写的一个小应用写测试代码，主要是为了学习测试的流程，没写一会，就发现，我之前有些代码写的根本不具备可测试性。我问同事，碰到这种情况怎么办，他说，改实现代码，再接着写测试代码（我们目前没有进行TDD开发，测试代码都是后期补的）。所以我想，既然要去返工，其实也就证明自己写的代码是不合格的，转念一想，如果自己写的代码，某天不是自测，而是他人测试时，被改的“面目全非”，那岂不是很惭愧。因此一定要真正写过测试代码了，再去带着写可测试代码的那种想法去写代码，你这个环节的质量合格，整体质量和效率才会提高。经过长期的练习与实践，当这种想法已经成为编码习惯，那么才有资格说自己是个合格的程序员。

事实上我不得不抱怨Android测试框架，真的很难用。当你使用Android测试api，如果使用错误，这个框架几乎不会给我报告有用的信息让你track问题。就在刚才，我花了几个小时在找一个看起来挺蠢的问题。（见http://code.google.com/p/android/issues/detail?id=8501，碰到这样的问题，真是泪奔）。所以，1.记得给那些你要用到的类加上一个public的无参构造器。2.记得不要开多个ide，然后再运行测试代码。

如何控制和监控Activity的生命周期，以达到测试的目的？有一种做法，就是克隆Activity的

生命周期控制api（题外话：生命周期api，onCreate，onResume等，如果要从设计模式来看，不就是Template Methods吗）。然后定义一个基类Activity实现这些克隆，让克隆api和Activity自由的生命周期api联系起来（让这个基类成为一个facade）。当要测试某个Activity时，只要给基类里的克隆api接口变量注入一个实现实例即可。可能没说清楚，就让代码来解释：

package com.nsworks.testdemo.util;

import android.app.Activity;
import android.os.Bundle;

/**
 * The super base activity for all activities, each activity should inherit it.
 */
public class BaseActivity extends Activity {
	public interface ActivityLifeCycleController {
		public void onCreate(BaseActivity instance, Bundle myCycle);
		public void onStart(BaseActivity instance);
		public void onResume(BaseActivity instance);
		public void onPostResume(BaseActivity instance);
		public void onPause(BaseActivity instance);
		public void onStop(BaseActivity instance);
		public void onDestroy(BaseActivity instance);
	}
	// Note: this field must be declared static in order to be injected
	// in test framework implementations.
	private static ActivityLifeCycleController mCycleController;
	// Note: Android test framework need each class to have a public constructor
	// without any parameters
	// I think this is weird, but if a class has not a such constructor will
	// cause a failure.
	public BaseActivity() {
		// Do something
	}
	@Override
	protected void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		if (mCycleController != null) {
			mCycleController.onCreate(this, savedInstanceState);
		}
	}
	@Override
	protected void onStart() {
		super.onStart();
		if (mCycleController != null) {
			mCycleController.onStart(this);
		}
	}
	@Override
	protected void onResume() {
		super.onResume();
		if (mCycleController != null) {
			mCycleController.onResume(this);
		}
	}
	@Override
	protected void onPostResume() {
		super.onPostResume();
		if(mCycleController != null) {
			mCycleController.onPostResume(this);
		}
	}
	@Override
	protected void onPause() {
		super.onPause();
		if (mCycleController != null) {
			mCycleController.onPause(this);
		}
	}
	@Override
	protected void onStop() {
		super.onStop();
		if (mCycleController != null) {
			mCycleController.onStop(this);
		}
	}
	@Override
	protected void onDestroy() {
		super.onDestroy();
		if (mCycleController != null) {
			mCycleController.onDestroy(this);
		}
	}
}

接着，所要做的是在测试环境初始化的过程中加入注入操作：

MemberAccessor.searchSuperField(DayActivity.class, "mDbFacade", new MockCTDbFacade());

看看MemberAccessor工具类的实现：

	public static Class<?> searchSuperField(Class<?> target, String fieldName, Object value) throws SecurityException, IllegalArgumentException, IllegalAccessException{
		if(target == null) 
			return null;
		
		if(target.getClass().equals(Object.class))
			return null;
		
		Field field = null;
		
		try {
			field = target.getDeclaredField(fieldName);
			field.setAccessible(true);
			
		} catch (NoSuchFieldException e) {
			searchSuperField(target.getSuperclass(), fieldName, value);
		}
		
		if(field != null) {
			field.set(null, value);
		}
		return target;
	}

注意:被注入的变量一定要是静态的。
这只是思路，提升Activity的可测试性。

给面向接口编程优点之一：提高可测试性。譬如说设计Mock的时候，安逸啊。。

命令行下执行测试代码必备命令：adb shell pm（万恶的google文档，让我按照tutorial折腾了几个小时，也没有弄出来，结果SO上一个回答搞定。。可恶,##）。

如果有命令不明白，去看InstrumentationTestRunner类的doc非常有帮助。

设计良好的intent结构，能提高可测试性。单元测试、Instrumentation测试时，使用intent控制程序流程相当容易，monkey测试时更是如此。其实根据我第一个小demo的经验来看，最容易不写intent的地方就是activity的跳转控制，所以这可能是一个需要注意的地方。

//待续