位置: 编程技术 - 正文
Android 进行单元测试难在哪-part3(安卓实现单选题)
编辑：rootadmin推荐整理分享Android 进行单元测试难在哪-part3(安卓实现单选题)，希望有所帮助，仅作参考，欢迎阅读内容。
文章相关热门搜索词:android 单例模式使用场景,android 单例模式使用场景,android单选按钮代码,android 单元测试教程,android单选按钮代码,android单activity,安卓实现单选题,android单选,内容如对您有帮助，希望把文章链接给更多的朋友！
在 Android 应用中进行单元测试很困难，有时候甚至是不可能的。在之前的两篇博文中，我已经向大家解释了在 Android 中进行单元测试如此困难的原因。而上一篇博文我们通过分析得到的结论是：正是 Google 官方所提倡的应用架构方式使得在 Android 中进行单元测试变成一场灾难。因为在官方提倡的架构方式中，Google 似乎希望我们将业务逻辑都放在应用的组件类中（例如：Activity，Fragment，Service，等等……）。而这种开发方式也是我们一直以来使用的开发模板。
在这篇博文中，我列举出几种架构 Android 应用的方法，使用这些方法进行开发能让单元测试变得轻松些。但正如我在序中所说，我最推崇的办法始终是 Square 发布的博文： Square：从今天开始抛弃Fragment吧！ 中所用的通用方法。因为这个方法是由 Square 中的 Android 开发工程师想出来的，所以我会在接下来的博文中将这个办法叫作“Square 大法”。
Square 大法的核心思想是：把应用组件类中的业务逻辑全部移除（例如：Activity，Fragment，Service，等等……），并且把业务逻辑转移到业务对象，而这些业务对象都是被依赖注入的纯 Java 对象，以及与 Android 无关的接口在此的 Android 特定实现。如果我们在开发应用的时候使用 Square 大法，那进行单元测试就简单多了。在这篇博文中，我会解释 Square 大法是如何帮助我们重构 UI 无关的应用组件（例如我们在之前的博文中讨论的 SessionCalendarService），并让对它进行单元测试变得容易许多。
用 Square 大法重构 UI 无关的应用组件用 Square 大法重构类似于 Service，ContentProvider，BroadcastReceiver这样的 UI 无关的应用组件相对来说比较容易。我再说一次我们要做的事情吧：把在这些类中的业务逻辑移除，并把它们放到业务对象中。
由于“业务逻辑”是很容易有歧义的词语，我来解释下我使用“业务逻辑”这个词时，它所代表的含义吧。当我提到“业务逻辑”，它的含义和维基百科上的解释是一致的：程序中根据现实世界中的规则用于决定数据将如何被创建，展示，储存和修改的那部分代码。那么现在我们就可以就“业务逻辑”这个词的含义达成共识了，那就来看看 Square 大法到底是啥吧。
我们先来看看怎么用 Square 大法实现我在之前的博文中介绍的 SessionCalendarService 吧，具体代码如下：
如你所见，SessionCalendarService 调用了将要在后面定义的 helper 方法。一旦我们将这些 helper 方法和类的字段声明也考虑进来，Service 类的代码就有多行。要 hold 住这么庞大的类内发生的业务逻辑可不是什么简单的活，而且就像我们在上一篇博文中看到的那样，要在 SessionCalendarService 中进行单元测试简直是天方夜谭。
那现在来看看用 Square 大法实现它代码会是怎样的。我再强调一次：Square 大法需要我们将 Android 类内的业务逻辑迁移到一个业务对象中。在这里，SessionCalendarService 所对应的业务对象则是 SessionCalendarUpdater，具体代码如下：
我想要强调其中的一些要点：首先，需要注意，我们完全不需要用到任何新的关键字，因为业务对象的依赖都被注入了，它根本不会使用新的关键字，而这正是让类可单元测试的关键。其次，你会注意到类没有确切地依赖于 Android SDK，因为业务对象的依赖都是 Android 无关接口的 Android 特定实现，因此它不需要依赖于 Android SDK。
那么这些依赖是怎么添加到 SessionCalendarUpdater 类中的呢？是通过 SessionCalendarService 类注入进去的：
值得注意的是，修改后的 SessionCalendarService 到处都是新的关键字，但这些关键字在类中并不会引起什么问题。如果我们花几秒时间略读一下要点就会明白这一点：SessionCalendarService 类中已经没有任何业务逻辑，因此 SessionCalendarService 类不再需要进行单元测试。只要我们确定在 SessionCalendarService 调用的是 SessionCalendarUpdater 类中的 updateCalendar() 方法，在 SessionCalendarService 唯一可能出现的就是编译时错误。我们完全不需要为此实现测试单元，因为这是编译器的工作，与我们无关。
由于我在前两篇博文中提到的相关原因，将我们的 Service 类拆分成这样会使对业务逻辑进行单元测试变得非常简单，例如我们对 SessionCalendarUpdater 类进行单元测试的代码可以写成下面的样子：
结论为了能够进行单元测试，我认为修改后的代码变得更易读和更易维护了。可以肯定的是，我们还有许多办法能让代码变得更好，但在让代码能够进行单元测试的过程中，我想让修改后的代码尽可能与修改前风格相似，所以我没有进行其他修改。在下一篇博文中，我将会教大家如何使用 Square 大法重构应用的 UI 组件（例如：Fragment 和 Activity）。
Android UI开源框架 1.Side-Menu.Android分类侧滑菜单，Yalantis出品。项目地址：
Android之取消ViewPage+Fragment的预加载 Android之取消ViewPageFragment的预加载用过ViewPageFragment组合的童鞋自然知道这个问题，没有遇到的同学祝愿你们永远不会遇到，呵呵。直接上关键代码注释
android-MAT使用 转载：
标签: 安卓实现单选题
本文链接地址:https://www.jiuchutong.com/biancheng/384205.html 转载请保留说明！上一篇：android之startActivityForResult的使用
