需求千萬條，質量第一條單元測試的前生今生

和標題是一樣的：需求千萬條，質量第一條，保證**的質量是開發者應該具備的硬性能力。

其實很多開發者都明知道單元測試很重要，但是為什麼還那麼反感單元測試呢？

原因有三：

1.單元測試太浪費時間了，很多需求都做不完，哪有功夫閒心去做單元測試，如果做單元測試，完成不了需求，程式猿是需要背鍋的，所以為了不背鍋只能捨棄單元測試了。

2.為什麼要寫單元測試，既然都測試人員了，為什麼還要寫單元測試呢？

3.單元測試的成本太高，任何需求改動了都會造成單元測試的修改。

就上面的三個問題乙個個解決掉。

第乙個問題：需求太多，單元測試時間不夠，很多邏輯都寫不完，哪有時間去寫單元測試。

解決方法：並不是所有的**去寫單元測試，比如說網路請求的**，這段**是否需要單元測試，答案當然是否定了。相信現在的第三方庫的單元測試比所有開發者寫的都好，所以只需要單元測試自己開發過程中的核心**。

這個就是retrofit的單元測試，感覺還需要測試retrofit這個庫嗎？你自己開發的**裡還需要測試這個嗎？

那麼開發者應該測試什麼**？就是邏輯**，身為乙個android開發者，網路請求不需要測試，那麼就需要對返回資料進行處理的時候測試的

private string getmessage(networkmessage networkmessage)else if (networkmessage.getcode()==2002)
........
return null;
}

上述**就是網路請求返回的結果，最簡單的方法就是封裝乙個方法，可以僅僅測試這乙個方法。如果以後增加一些需求就可以在這個方法裡不斷增加。

第二個問題：既然有qa，為什麼還需要程式猿自測呢，這不是資源重複使用嗎？

程式猿的單元測試是對**質量的一種肯定，核心**僅僅靠qa的測試是不靠譜的。核心**還需要程式猿來測試，只有寫這個**的人才最了解**。

以上述**為例子：

假如networkmessage這個引數是空的，那麼上述**就會崩潰，但是這段**是qa無法覆蓋的地方，因為他們不確定是否能返回，也無法模擬這種情況，這樣的情況下就**也不健壯，如果這種情況下發生一次就會崩潰，但是這種情況下是不一定能復現，相信說到這，開發者應該明白了吧。

第三個問題：單元測試的成本太高了，其實這個很好解決，不斷將**細化，只單元測試核心的內容，簡單的函式方法就需要去單元測試了，就可以了節省一大部分的時間以及**，只做最核心的**邏輯就好了。如何來界定核心**呢？

第乙個就是和金錢有關的**，第二個就是你認為的核心邏輯**。

因為錢造成的損失是公司最反感的。第二個很容易理解，每個專案的核心邏輯都不一樣，所以就需要自己來掌握。

上述三個問題都解決了，總結下來:不需要測試第三庫的**，單元測試**中和金錢有關以及核心邏輯**，這樣可以節省**的時間以及保證**的健壯性。

需求千萬條，質量第一條 單元測試的前生今生