最近，在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){ //.. } }); |
应用到我们自己的测试集合后，当得到预期之外的结果时，只是让这一结果失败。我们可以看到为什么在onFailure()函数中我们调用了fail()。接下来，即使我用一个错误的用户名也能通过这个测试。思前想后，测试似乎是按照代码顺序执行的，但并没有等到回调函数的结果返回再向下执行。
这显然不是一个好方法。因为现在的程序经常通过异步任务和回调方法从后台获取数据。尝试UIThread测试仍然不行。
最后，我发现下面这种方法可以行得通。只是用简单的CountDownLatch信号对象来实现wait-notify机制（你也可以用syncronized(lock){...lock.notify();}，只是这样代码并不美观而已）
那么之前的代码就变成了下面的模样：
finalCountDownLatchsignal=newCountDownLatch(1); mLoginManager.performLoginWithUsername("username","password",newOnLoginListener(){ @Override publicvoidonFailure(Throwablethrowable){ fail(); signal.countDown(); } Override publicvoidonSuccess(Usercustomer){ signal.countDown(); } }); signal.await(); |