深度剖析Android单元测试问题


  本文标签:Android单元测试

  许多人在接触到Android单元测试时,第一反应是Android单元测试是不是已经完整集成了JUnit  。很遗憾这不是事实  。如果你按照JUnit的运行方法,却不像上面那样改用JDK,就一定会得到一个异常  。

  实际上,TestCase这个类用于在Android担当所有独特的TestCase的基类的作用,它是一个Abstract Class  。Android单元测试类继承关系图如下所示:

  1. #  
  2. # An unexpected error has been detected by Java Runtime Environment:   
  3. #  
  4. # Internal Error (classFileParser.cpp:2924), pid=4900tid=4476   
  5. #Error: ShouldNotReachHere()   
  6. #   
  7. # Java VM: Java HotSpot(TM) Client VM (10.0-b19 mixed mode windows-x86)   
  8. # An error report file with more information is saved as:   
  9. # E:\Mydoc\EclipseWorkspace\TestAndroid\hs_err_pid4900.log   
  10. #   
  11. # If you would like to submit a bug report, please visit:   
  12. # http://java.sun.com/webapps/bugreport/crash.jsp   
  13. #  

  之所以有那么多XXXTestCase主要是为了简化工作  。例如当你想对一个访问数据库的功能进行测试时,首先需要自己启动并初始化数据库  。在这里是类似的,如果你想测试一个Activity  。

  首先要启动它  。而ActivityTestCase就会自动帮你做完这些事情  。而ActivityUnitTestCase会更注重测试的独立性,它会让测试与Android单元测试的联系降到最低  。其余的类可以查看相关的Javadoc来按需挑选  。要编写测试,就是找到合适的XXXTestCase作为基类来继承,并且编写自己的测试方法  。

  很明显的,最简单的编写测试的方法就是继承Android单元测试写一个自己的TestCase  。然后为自己的一组TestCase写一个Activity界面,由界面控制TestCase的启动,运行和结果报告  。

  但是,你很快会发现,为何要给测试写一个界面呢?这太诡异了  。这时就需要一种技术,它可以利用命令行(Shell)来启动一组测试,并且通过命令行的形式给出结果  。这就是所谓的Instrumentation  。

  在Java下做单元测试必然用到JUnit  。这里说的JUnit是指从Apache基金会下载的junit.jar里提供的一系列单元测试功能  。这些功能显然是运行在JDK之上的  。在Android下已经没有了JDK  。

  自然也无法运行JUnit  。但是这并不妨碍我们利用JUnit编写单元测试  。只不过在运行单元测试时,一定要用JDK来运行,利用java命令来启动JUnit的某个Runner  。如果是用Eclipse的话,可以在Run Configuration里新建一个JUnit  。但是一定要记得在Classpath选项卡里将Bootstrap Entries中的Android Library改成JRE,并且添加junit.jar  。

  这样,在启动程序的时候就会先启动一个Application,然后在此Application运行过程中根据情况加载相应的Activity,而Activity是需要一个界面的  。但是Instrumentation并不是这样的  。你可以将Instrumentation理解为一种没有图形界面的,具有启动能力的,用于监控其他类(用Target Package声明)的工具类  。任何想成为Instrumentation的类必须继承