2011-08-30 29 views
0

爲了對涉及Android狀態欄的代碼使用測試驅動的開發原則,我需要編寫測試來驗證預期狀態已經實現。例如,像下面的一個小單元測試,讓我覈實,我打算忍受通知實際上顯示:我可以爲Android狀態欄通知做TDD嗎?

public class NotificationTest extends AndroidTestCase { 

    public void testCanNotify() { 
    // setup SUT 
    NotificationManager mgr = (NotificationManager) getContext().getSystemService(
      Context.NOTIFICATION_SERVICE); 
    Notification notif = new Notification(android.R.drawable.stat_notify_error, "ticker", 0); 
    PendingIntent intent = PendingIntent.getActivity(getContext(), 0, null, 0); 
    notif.setLatestEventInfo(getContext().getApplicationContext(), "title", "text", intent); 
    int id = 123; 

    // exercise SUT 
    mgr.notify(id, notif); 

    // verify result 
    // QUESTION: HERE I WOULD LIKE TO SAY: 
    // assertTrue(mgr.isShowing(id)); 

    // teardown 
    mgr.cancel(id); 
    } 
} 

因此,作爲例子顯示,通知管理器本身似乎並不具有任何診斷方法,例如isShowing(id)get(id),我可以將它們用於測試中的「驗證」步驟。

我已經看過了優秀Robotium工具包,但他們都非常具體的關於測試的一個應用程序,所以他們不涵蓋通知。

有誰知道解決方案嗎?

回答

3

通常我不會測試第三方或系統API是否按預期工作。我將使用模擬NotificationManager並驗證我的生產代碼是否使用正確的參數調用notify真正的NotificationManager行爲是否正確並不是你控制的東西。

如果NotificationManager是嘲諷你可以嘗試在薄類,你的控制之下的包裝產生抗藥性。

我唯一一次測試第三方或系統API是當它被不良記錄,我需要確認有關其行爲的猜測。一旦我有了答案,這些測試通常會被拋棄。如果是這種情況,並且發現使用測試框架進行測試很困難,則可以始終創建一個簡單的應用程序並以可視方式驗證結果。

+0

謝謝,這對我有意義。實際上,其目的不是測試通知管理器,而是測試我自己的各種活動之間的交叉依賴關係。我明白你的意思,這最好是在模擬的背景下完成 - 我會研究這一點。 – marc1s