最近,在Sixt(德国比较大的一个汽车租赁网站)上,我们把我们的开发环境从Eclipse迁移到Android Studio。这也就意味着我们进入了新的编译系统——Gradle,并且把TDD(测试驱动开发)和CI(持续集成)纳入我们的软件开发流程。这里不是 讨论在软件开发中引入CI会带来怎样的好处,而是讨论在Android中当测试UI之外的线程时会出现的问题。
Android中的测试(宽泛的定义)是一个单元测试集合的扩展。涉及初始化、关闭测试,包含setUp()和tearDown()操作,使用反射 的方式推断出不同的测试方式(从JUnit4开始我们就可以使用注释来指定的优先级和执行所有测试)。一个典型的测试结构如下:
- public class MyManagerTest extends ActivityTestCase {
- public MyManagerTest(String name) {
- super(name);
- }
- protected void setUp() throws Exception {
- super.setUp();
- }
- protected void tearDown() throws Exception {
- super.tearDown();
- }
- public void testDummyTest() {
- fail("Failing test");
- }
- }
这是一个非常明显的示例:实际开发中,我们想要测试例如HTTP响应、SQL存储等等。在Sixt我们遵从一种Manager/Model方法:每 个Model包含一个实体(车、顾客等)的表现。每个Manager用不同的模型(例如,我们的LoginManager可能需要用户与之交互的模型)聚 合成一套功能。
大多数的Manager集中执行HTTP请求是要从后台获取数据。例如,我们用下面的代码来执行用户的登录:
- mLoginManager.performLoginWithUsername("username", "password", new OnLoginListener() {
- @Override
- public void onFailure(Throwable throwable) {
- fail();
- }
- Override
- public void onSuccess(User customer) {
- //..
- }
- });
应用到我们自己的测试集合后,当得到预期之外的结果时,只是让这一结果失败。我们可以看到为什么在onFailure()函数中我们调用了 fail()。接下来,即使我用一个错误的用户名也能通过这个测试。思前想后,测试似乎是按照代码顺序执行的,但并没有等到回调函数的结果返回再向下执 行。
这显然不是一个好方法。因为现在的程序经常通过异步任务和回调方法从后台获取数据。尝试UIThread测试仍然不行。
***,我发现下面这种方法可以行得通。只是用简单的CountDownLatch信号对象来实现wait-notify机制(你也可以用syncronized(lock){... lock.notify();},只是这样代码并不美观而已)
那么之前的代码就变成了下面的模样:
- final CountDownLatch signal = new CountDownLatch(1);
- mLoginManager.performLoginWithUsername("username", "password", new OnLoginListener() {
- @Override
- public void onFailure(Throwable throwable) {
- fail();
- signal.countDown();
- }
- Override
- public void onSuccess(User customer) {
- signal.countDown();
- }
- });
- signal.await();