Android、JUnit深入浅出（七）——总结篇

 

在学习Android、JUnit的过程中，随着学习的深入，将Android、JUnit的类按照继承关系整理如下：

• Test—TestCase—AndroidTestCase
• Test—TestCase—InstrumentationTestCase
• Test—TestSuite—InstrumentationTestSuite
• TestListener——BaseTestRunner—AndroidTestRunner
• Instrumentation—InstrumentationTestRunner

上面的5条路线，也是我们不断学习的过程，对于前4条路线感觉自己解析的都比较清楚，最后一条路线似乎说的不是很清楚，后来我又查看了不少这方面的资料，对Instrumentation再次说明下。

每个Android 应用程序运行在自己的进程，Instrumentation杀死当前应用程序，并重新启动应用程序（restarts the process with Instrumentation）。Instrumentation提供给我们一个应用程序上下文的Handle，通过这个Handle我们可以洞察应用程序，从而验证测试断言，我们还可以通过它来写一些比界面测试更加底层的测试用例。需要强调说明的是：Instrumentation不能捕获UI方面的bugs。

Android在JUnit的基础上扩展出来的、与Instrumentation有关的3个类:

类	描述
InstrumentationTestCase	它扩展了JUnit中的TastCase，并提供了一个接口getInstrumentation() 获取Instrumentation类。这个可以根据自己的需求来扩展这个类，比如说：测试中可能会启动某个Avtivity和发送按键事件，为此完成测试，instrumentation需要将其注入到TastCase中。
InstrumentationTestRunner	它是Instrumentation的基础上扩展的，它将自己注入到每个测试用例本身，测试用例需要分组到一个适当的InstrumentationTestRunner运行起来。
InstrumentationTestSuite	它扩展了JUnit TestSuite，其主要作用是保证每个TestCase在运行前，Instrumentation能注入到TestCase中，InstrumentationTestRunner中需要使用InstrumentationTestSuite。

以上说明来自网页Instrumentation Testing（英文的），在这里推荐给大家阅读。

JUnit的使用心得

JUnit是采用测试驱动开发的方式，也就是说在开发前先写好测试代码，主要用来说明被测试的代码会被如何使用，错误处理等；然后开始写代码，并在测试代码中逐步测试这些代码，直到最后在测试代码中完全通过。

看了是否感觉有些不符合程序员的思维习惯（先写代码然后在调试），的确这也是JUnit是对程序员思维习惯的“颠覆”。在这里我自己也感觉，好像很难做到，为什么？在一匹“马”没有完全设计好前，怎么规定这匹“马”将来会如何跑？而且即使把“马”将来会如何“跑”定义好了，在实现的时候“马”被改变了怎么办？说到底还是：一个人不能同时具有2个角色，否则自己有时候就不知道当前是哪个角色！

说到这里，我就说明下，我自己对JUnit “错误”的使用方法，这也许与JUnit测试驱动开发的目的相矛盾，但是的确可以有效地减少bug。JUnit从核心来说就是将源代码与测试代码完全分开，将测试代码作为一个单独的程序。前面介绍的方法，都将源代码与测试代码合为一体，由于源代码的重要性大于测试代码的重要性，所以测试代码经常有不完整、结构不清晰等问题，这样程序员的单元测试也就不完整。JUnit就是被我用来做完整的单元测试，对当前的部分代码，测试其在每种“环境”下的运行结果。

后记说明

历时半个月的学习，总算把Android、JUnit深入解析篇写完了，还是比较全面的介绍了Android中使用JUnit的方方面面，在写博客的过程中，我也尽量把自己遇到的每个问题，在这里与大家分享，并尽量把每个问题解析清楚。如果你看了之后，感觉有什么不足、错误、遗漏的地方，欢迎大家在博客中留言。