摘要: 最近,在Sixt(德国比较大的一个汽车租赁网站)上,我们把我们的开发环境从Eclipse迁移到AndroidStudio。这也就意味着我们进入了新的编译系统——Gradle,并且把TDD(测试驱动开发)和CI(持续集成)纳入我们的 ...
最近,在Sixt(德国比较大的一个汽车租赁网站)上,我们把我们的开发环境从Eclipse迁移到AndroidStudio。这也就意味着我们进入了新的编译系统——Gradle,并且把TDD(测试驱动开发)和CI(持续集成)纳入我们的软件开发流程。这里不是讨论在软件开发中引入CI会带来怎样的好处,而是讨论在Android中当测试UI之外的线程时会出现的问题。 Android中的测试(宽泛的定义)是一个单元测试集合的扩展。涉及初始化、关闭测试,包含setUp()和tearDown()操作,使用反射的方式推断出不同的测试方式(从JUnit4开始我们就可以使用注释来指定的优先级和执行所有测试)。一个典型的测试结构如下: |
publicclassMyManagerTestextendsActivityTestCase{publicMyManagerTest(Stringname){super(name);}protectedvoidsetUp()throwsException{super.setUp();}protectedvoidtearDown()throwsException{super.tearDown();}publicvoidtestDummyTest(){fail("Failingtest");}} 这是一个非常明显的示例:实际开发中,我们想要测试例如HTTP响应、SQL存储等等。在Sixt我们遵从一种Manager/Model方法:每个Model包含一个实体(车、顾客等)的表现。每个Manager用不同的模型(例如,我们的LoginManager可能需要用户与之交互的模型)聚合成一套功能。 大多数的Manager集中执行HTTP请求是要从后台获取数据。例如,我们用下面的代码来执行用户的登录:mLoginManager.performLoginWithUsername("username","password",newOnLoginListener(){@OverridepublicvoidonFailure(Throwablethrowable){fail();}OverridepublicvoidonSuccess(Usercustomer){//..}});