近，在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(){
@Override
publicvoidonFailure(Throwablethrowable){
fail();
}
Override
publicvoidonSuccess(Usercustomer){
//..
}
});