Android开发笔记之:对实践TDD的一些建议说明
发布时间:2023-11-25 11:45:18
最近部分采用了TDD的方法来开发一个模块,小有收获特此总结一下:
1. TDD的基本原则
TDD的最核心思想就是先明确需求,且用代码的方式量化,明确需求标准,然后进行编码实现以达成由代码测试来衡量的标准。
那么它要求,先把需要标准写出来,每次只写一个。编码实现通过达到,并刚好满足这个标准。这样一点一点的迭代。
这样有三个好处:一个是先明确标准,不至于我们迷失主题,偏离方向。有标准在检测,保证代码是正确的。仅满足当前测试,不至于过早优化和过度设计。
2. TDD的难点
难点在于如何设计这个测试标准,
1)让它足够小,是一个需求单元;
2)成为标准,也就是如何检测正确性;
3)就是如何在最大程度模拟真实运行的场景,而不是为了测试而写出许多额外的工具,也就是说测试应该跟真实的项目代码一样,不应该有多余的东西。
这关键在于要分析挖掘需求,并细化需求。如果都像书中的例子那样测试一些API那倒是很好写,因为测试代码跟真实的App代码用一样的方式来调用API,而且API的功能也会有明确的描述。但现实情况并非如此,比如很多框架就很难测试,很多对象和创建和控制都是由框架来做,你无法像控制。这就导致了很难写测试用例。
还有就是多线程,由于线程带来的不确定性,有很多伪失败,这可以参考书,书中有方法。
3. Android中的TDD
老实说,在Android完全用TDD的方法来开发是不可能的。原因如下:
1. Android中的应用程序主要结构是四大组件:Service,Activity和Provider和Receiver这四东西的创建和销毁都是由框架来控制。所以你不可能像书中例子那样去测试它们,因为有些限制让你无法用代码来测试。
2. 有些东西是系统框架的回调或者很基本东西根本不用写TestCase。比如View的Click/LongClick/Touch事件的处理之类的,或者Activity的生命周期回调,或者OptionsMenu/ContextMenu之类的。
3. SDK中的用于测试的API功能太弱
这就导致了,为了测试一个小功能需要做很多工作和写很多代码,远大于直接实现。比如测试一个弹出的Dialog,如果直接实现很容易;但如果用代码来测试就要多3,4倍的工作量,远大于直接实现。
4. 那么在Android中应该如何运用好TDD呢?以下是一些建议:
1. 使用Robotium
这是强大的工具,它比SDK中的东西可是方便的很多比如searchText,clickMenu之类的接口非常的方便和实用。
2. 自动测试+手动测试
同样要遵循原则,但是对于测试用例,没有必要完全用代码来写,可以部分手动测试:一般的原则来讲如果自动测试比较方便的实现就写TestCase,如果手动测试很方便就手动测试,这没有死规则要看具体的情况。
比如,View的事件,Activity的事件,Activity的Menu,Dialog之类的与交互相关的东西,以及跨应用交互的用例最好手动来测试,因为这些东西用代码来测试更麻烦。
但对于一些涉及数值,计算,量化等就用代码来做。比如下载一个文件,设定好路径后就可以直接用File对象来检测文件是否下载成功。
3. Provider必须要测试
Provider提供的是API,它非常好测试也容易写,又是一个项目的基本设施,所以必须要好好测试,否则如果在Activity上某条数据有问题,你必须要确定是显示上出了问题还是Provider里出了问题。通常CRUD必须测试,还有就是where语句,以及逆向测试,必须要检测Uri的合法性等,还有就是要检测对特殊字符的处理,比如'和"。
4. 除Service和Activity以外的东西,特别是自己实现的类似API的类,如果里面涉及一些业务逻辑也要进行测试。这就跟书中的例子差不多了,测试的难易成就也取决于业务的分解,设计和耦合度了。
5. 用反射来测试类的内部
对于Service和Activity虽然可以在TestCase中拿到它的实例,但是Service和Activity是一个组件单元在实际中并不会Public太多的接口,它们是处于最顶端的调用其他接口,而自己不会,也不应该公开接口给别人用,原因就是它们的创建和生命周期的管理都是由系统控制的,别处不应该有太多对它们的引用。
那么当要测试Service和Activity内部时怎么办呢?比如要测试某个Service内部的一个int[] mPlaylistQueue。我们总不能为了写Case而在Service中加接口吧!这时就要用反射机制来取出这个成员的实例,然后检查它的数据。
6. 有些东西必须手动测试,自动化无法完成
TestCase是有特殊的Context和MockObject的,它是对真实Android运行的一个最大化的模拟,它并不跟应用真正运行时的情况完全一样!而且由于Permission的原因,某些事情Instrumentation是无法做的,比如Alarm,日期等Instrumentation是无权限更改的。这些必须要靠手动测试。
还有就是Service和Activity的初始化和销毁,特别是销毁,没办法测试,也就是说对于onDestroy()里面的东西,还真的不好去测试。第一,你不知道它何时被回调到;第二,执行到它时对象快被销毁了,你持有的引用不一定有效了;第三,成员对象是否都有效也无法得知。对于onDestroy只能通过调试手段手动的去测试。
总之,在我看来,TDD的核心思想是测试先来,实现后来。但如何测试并没有列规定非要用代码,所以根据实际情况,选择最佳的测试手段。
猜你喜欢
- 前言众所周知在spring boot内,设置session过期时间只需在application.properties内添加server.se
- 1:Xxtea支持中文;2:支持JS和C#加解密之间的互转;一:C#部分class XXTEA2 {
- 在后端数据接口项目开发中,经常遇到返回的数据中有null值,导致前端需要进行判断处理,否则容易出现undefined的情况,如何便捷的将nu
- 介绍本篇主要介绍kafka的 * 和序列化器,序列化器是和数据在网络中的传输有关,数据在网络中的传输为字节流,所以生产者在发送时需要将其序列
- 本文是一个 Spring 扩展支持 SPEL 的简单模式,方便第三方通过 Spring 提供额外功能。简化版方式这种方式可以在任何能获取Ap
- 1. 背景我们都知道,Compose可以使用mutableStateOf和UI进行绑定,改变值之后,就可以改变UI。var value by
- 开发项目的时候,表很多,是不可能一点点的自己去写xml ,dao文件的,这里就需要用到代码的自动生成工具了。第一步:导入jar包,当然,这之
- 网络爬虫在信息检索与处理中有很大的作用,是收集网络信息的重要工具。接下来就介绍一下爬虫的简单实现。爬虫的工作流程如下爬虫自指定的URL地址开
- dependencyManagement一般出现在最顶层父工程的pom文件中,它的作用是用来管理jar版本,让子项目引用一个依赖而不用指明版
- 本文导读中秋节是中国民间的传统节日,中秋节源自天象崇拜由上古时代秋夕祭月演变而来。中秋节自古便有祭月、赏月、吃月饼等民俗,流传至今,经久不息
- settings.xml有什么用?如果在Eclipse中使用过Maven插件,想必会有这个经验:配置settings.xml文件的路径。se
- 1.launch启动流程已知协程的启动方式之一是Globalscope.launch,那么Globalscope.launch的流程是怎样的
- 单例模式,属于创建类型的一种常用的软件设计模式。通过单例模式的方法创建的类在当前进程中只有一个实例(根据需要,也有可能一个线程中属于单例,如
- 前言这篇博客介绍Java环境的配置,主要是安装JDK,以及path、JAVA_hOME、CLASSPAT的配置,还会介绍配置这些的原因。一.
- 假设下面是你的视频网站链接列表,如果别人想爬取你的数据十分轻松,看规则就知道数据库是序列自增的http://www.xxxx.com/vid
- 今天记录一下验证码的实现,希望能够帮助到大家!首先我们看一下实现的效果:此验证码的实现没有用到太多的插件,话不多说直接上代码,大家拿过去就可
- 二、简介多线程技术主要解决处理器单元内多个线程执行的问题,它可以显著减少处理器单元的闲置时间,增加处理器单元的吞吐能力,但频繁的创建线程的开
- 1.之前在使用AutoMapper 框架感觉用着比较不够灵活,而且主要通过表达式树Api 实现对象映射 ,写着比较讨厌,当出现复杂类型和嵌套
- 近期在项目中,策划给出了一个需求就是,让按钮按照一个轮盘的轨迹进行滑动的效果,经过一番测试,实现了初步的效果。我这里区分了横向滑动和纵向滑动
- 阅读目录(Content)•1.get与post的区别•1.1 get方法 jsp中的代码form表单代码•1.2 action包中serv