新的一年了，我卻在這里寫這個鬼

《重構(gòu)》的這一章主要是講java的一個測試框架，我直接就跳著看了

只是簡單的看了一下它的思想

• 重構(gòu)需要一個良好的測試體系，而我們需要為重構(gòu)構(gòu)建一個這樣的體系，這是重構(gòu)的前提
• 不需要期待完美測試，需要的是不完美的測試已經(jīng)在實際執(zhí)行了
• 測試的時候考慮可能出錯的邊界條件，并集中火力
• 不要因為測試無法捕捉所有BUG就不寫測試，至少它可以捕捉大多數(shù)
• 花合理的時間抓出大多數(shù)BUG
• 寫測試代碼去讓其執(zhí)行自動化測試

好了這就是本章主要的內(nèi)容

不太多，就來簡單談一下自己對測試的理解。

必要性與簡單的看法

之前的一件公司很注重BUG量，會有一個指標(biāo)，而我在之前的公司經(jīng)常會破掉這個指標(biāo)，然后花費大量的時間去找BUG，并去解決BUG。

實際上我可以以我自己的經(jīng)歷來說明這個東西的必要性，因為我并不是細(xì)心的程序員，但是我有非常好的耐心，而在我看來這個東西很適合我。

因為這是一個體系，雖然一開始不完善，但是我可以根據(jù)每一個測漏的BUG的反饋去不斷完善這個體系，它就會越來越盡善盡美。

我從來沒玩過單元測試和自動化測試，這個東西也并不在我近期的學(xué)習(xí)范圍內(nèi)。

我覺得如果我的代碼結(jié)構(gòu)還行，那么我本來就可以很快定位這個BUG，所以我近期不會去學(xué)這個東西。

唯一的麻煩就是我沒有這種自動化測試，那么我就不能即時的發(fā)現(xiàn)這個BUG，直到等到別人的反饋，并且在修改不熟悉代碼時控制關(guān)聯(lián)影響點也很難。

我的每一個BUG都不會為我將來的測試做出貢獻(xiàn)，真是令人遺憾！沒辦法，我要學(xué)的東西太多，這個排不上計劃！

再加上公司明年可能要在各個項目中推行單元測試，到時候可能再出一版單元測試的學(xué)習(xí)筆記吧。

所以我覺得這個東西很有用，但是我的需求暫時來說并不是很迫切，坐等被推動。

2016了，祝大家也祝自己新年快樂！