最近，在Sixt（德國比較大的一個汽車租賃網(wǎng)站）上，我們把我們的開發(fā)環(huán)境從Eclipse遷移到AndroidStudio。這也就意味著我們進(jìn)入了新的編譯系統(tǒng)——Gradle，并且把TDD（
測試驅(qū)動開發(fā)）和CI（持續(xù)集成）納入我們的
軟件開發(fā)流程。這里不是討論在軟件開發(fā)中引入CI會帶來怎樣的好處，而是討論在
Android中當(dāng)測試UI之外的線程時會出現(xiàn)的問題。
Android中的測試（寬泛的定義）是一個
單元測試集合的擴(kuò)展。涉及初始化、關(guān)閉測試，包含setUp()和tearDown()操作，使用反射的方式推斷出不同的測試方式（從JUnit4開始我們就可以使用注釋來指定的優(yōu)先級和執(zhí)行所有測試）。一個典型的測試結(jié)構(gòu)如下：
publicclassMyManagerTestextendsActivityTestCase{ publicMyManagerTest(Stringname){ super(name); } protectedvoidsetUp()throwsException{ super.setUp(); } protectedvoidtearDown()throwsException{ super.tearDown(); } publicvoidtestDummyTest(){ fail("Failingtest"); } } |
這是一個非常明顯的示例：實(shí)際開發(fā)中，我們想要測試?yán)鏗TTP響應(yīng)、
SQL存儲等等。在Sixt我們遵從一種Manager/Model方法：每個Model包含一個實(shí)體（車、顧客等）的表現(xiàn)。每個Manager用不同的模型（例如，我們的LoginManager可能需要用戶與之交互的模型）聚合成一套功能。
大多數(shù)的Manager集中執(zhí)行HTTP請求是要從后臺獲取數(shù)據(jù)。例如，我們用下面的代碼來執(zhí)行用戶的登錄：
mLoginManager.performLoginWithUsername("username","password",newOnLoginListener(){ @Override publicvoidonFailure(Throwablethrowable){ fail(); } Override publicvoidonSuccess(Usercustomer){ //.. } }); |
應(yīng)用到我們自己的測試集合后，當(dāng)?shù)玫筋A(yù)期之外的結(jié)果時，只是讓這一結(jié)果失敗。我們可以看到為什么在onFailure()函數(shù)中我們調(diào)用了fail()。接下來，即使我用一個錯誤的用戶名也能通過這個測試。思前想后，測試似乎是按照代碼順序執(zhí)行的，但并沒有等到回調(diào)函數(shù)的結(jié)果返回再向下執(zhí)行。
這顯然不是一個好方法。因?yàn)楝F(xiàn)在的程序經(jīng)常通過異步任務(wù)和回調(diào)方法從后臺獲取數(shù)據(jù)。嘗試UIThread測試仍然不行。
最后，我發(fā)現(xiàn)下面這種方法可以行得通。只是用簡單的CountDownLatch信號對象來實(shí)現(xiàn)wait-notify機(jī)制（你也可以用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(); |