什麼樣的單元測試，在android應用程序

Question

我的應用程序主要是圖形用戶界面通信服務器的大部分信息。如果出現任何問題，它通常會在網絡調用中或對JSON對象作出錯誤的假設。

單元測試不適合這些網絡相關和I/O相關的任務，否則它們不會被稱爲單元測試。

所以我試圖在我的案例中收集單元測試的觀點。爲什麼我會測試Android按鈕是否可以點擊或者EditText能夠看到我輸入的內容？我只是不明白，如果這上面的方法傳遞，這我所有活動的onCreate運行，那麼我知道該應用的工作原理implementating這些繁瑣的測試

private void initElements(){ 
    placeButton = (Button) findViewById(R.id.currplace); 
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation)); 
    placeButton.setEnabled(false); 
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout); 
    selectplaceLayout.setVisibility(View.GONE); 
    splash = (RelativeLayout)findViewById(R.id.splashbg); 
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout); 
} 

的效用。對其進行單元測試將是一件非常耗時的事情。耗費時間是因爲我不熟悉jUnit和Android測試框架中的所有方法。

那麼，長話短說，最重要的是什麼？我應該考慮這些測試有什麼特別的方法嗎？到目前爲止，我所見過的所有示例和教程都只是爲了簡潔而談論最簡單的示例，但我無法想到在主要的客戶端 - 服務器應用程序中進行單元測試的任何實際用途。

我希望通過訪問已經知道我已經聲明和初始化的android視圖來發現什麼？我必須思考這個在非常有限的方式

所以，有識之士意識到

Answer 1

有很多你的問題方面的，但我的意見 - 你可能不需要在你的項目單元測試。

當您需要大量業務邏輯到您的項目時，單元測試真的很有光芒。在這種情況下，您可能希望將應用程序劃分爲多層（比如三層體系結構），以便爲業務邏輯層添加一些自然隔離，並用單元測試的安全網絡覆蓋它。

這安全網覆蓋了業務層的重構在你的屁股，這是你從什麼單元測試（TDD可以提供一些不錯的額外的副作用雖然）的主要事情之一。

但是，它並不是所有的獨角獸和彩虹，單元測試可能會花費，有時它們會花費很多。良好的單元測試是孤立的（即處理小塊代碼）。這意味着您必須添加抽象層以便將您的類放在測試下。

這可能會對您的系統或消極系統產生積極影響。分層使得您的系統更加靈活，並且增加了複雜性。

有這樣的說 - 單位測試的價值與您將在項目中引入的抽象業務邏輯的數量成正比。你也可以這樣想 - 如果把抽象層添加到你的體系結構是矯枉過正的 - 不要添加單元測試 - 它們只會讓事情變得更加複雜（架構和構建明智）。

根據您的描述 - 您典型的應用程序往往是一些外部服務器端的表示層。除了在android手機上呈現信息並將用戶操作轉換爲主要業務邏輯完成（控制）的服務器端命令之外，它沒有那麼多。

通過這種方法，您可能編寫的大多數代碼都與「如何顯示這個和那個」或「如何在這種情況下發送服務器信號」相關。這種代碼顯然很大程度上取決於平臺，這意味着如果你想把它放在測試中，你將不得不嘲笑大量的Android特定的代碼行爲。

現在，Android是有些特定的平臺。它旨在兼顧性能優化，並允許開發人員快速啓動和生成應用程序。通常這意味着你使用的一些「瑞士刀」類擴展，通常這會加快編寫代碼的速度，但嘲笑這些類會變成一個真正的地獄。更何況，你必須瞭解平臺如何在引擎蓋下工作，以使這些模擬有用。換句話說，做這些測試的開銷會很高。

測試表示層的另一個問題是，它們往往比業務層更動態地變化。當然這意味着你必須重構你的測試，這會增加更多的開銷。

雖然我不得不說關於各種實用/幫助類的一件事。即使這些類屬於表示層，並且依賴於Android代碼，但是執行一些相當不重要的邏輯和也很容易爲它們模擬和編寫單元測試，但實際上這可能是一個好主意。但是，如果你確實有很多這樣的代碼 - 這可能表明你沒有設計好你的架構/分層，並且需要重新思考你在做什麼。

到底要回答你的問題，你必須先回答這些問題：

會否被過度設計補充說，從平臺到應用程序中分離抽象層（好像在你的情況下，它會） ？如果是 - 不要使用單元測試 - 他們只會減慢你的速度。如果沒有 - 使用它們。

你打算重構很多嗎？如果這是一個擁有大量代碼和維護的大型項目 - 那麼您可能會投入分層和單元測試（但是，一眼看來，這似乎並不是您的情況）。如果這不是你的情況 - 不要爲單元測試而煩惱，而且要快速。

您是否需要模擬平臺來編寫單元測試？如果是（似乎是你的情況） - 不要寫單元測試 - 他們不值得付出努力。

希望這會有所幫助。