前些天看見有朋友的MSN簽名檔寫著“unit testing”，就問了一下他們的單元測試是怎么做的。看來他們沒有真正做起來，只是小范圍的試一試。
一方面，他們沒有cruise control之類的工具，甚至連daily build都不見得有，單元測試也不上傳到版本控制里。這樣做測試的意義就不大了。
另一方面，他好像把單元測試和接收測試(acceptance testing)、集成測試(integration testing)搞混淆了。因為他說，業(yè)務(wù)邏輯很復(fù)雜，測試數(shù)據(jù)不好做……
單元測試，顧名思義，就是對一個單元的測試(好像什么也沒說)。通常這個單元是指(類的成員)函數(shù)，或者函數(shù)的一個功能。
每個測試就只針對一點，不涉及其余，還是比較好寫的。函數(shù)的輸入是什么，(對象當(dāng)時的狀態(tài)是什么)，得到的輸出是什么;有幾種不同的情況……
我感覺，同一個函數(shù)的單元測試加在一起，就相當(dāng)于這個函數(shù)的詳細(xì)設(shè)計文檔。自然，設(shè)計文檔應(yīng)該在實現(xiàn)之前寫，而不是實現(xiàn)了以后再補(bǔ)。
和傳統(tǒng)開發(fā)方法里的詳細(xì)設(shè)計不同，寫一個單元測試，就寫一段代碼讓它通過。這樣你就不需要在實現(xiàn)的時候，再去讀文檔，再去回憶當(dāng)時是怎么想的，能提高效率;更重要的是，這個“文檔”是能反復(fù)運(yùn)行的，可以保證和實現(xiàn)的一致性。
如果你的開發(fā)環(huán)境配置的好，照我的經(jīng)驗，寫單元測試再寫代碼，和直接寫代碼相比，不會多花什么時間。
編碼過程中有相當(dāng)一部分時間是花在想清楚下一步要做什么上，想到了就把它寫成一個測試。這么做是要花一點點時間，不過能幫你盡快驗證下面的實現(xiàn)跟你現(xiàn)在想的一致;能幫你理清思路，到底有幾種情況需要考慮，就寫幾個測試;能讓函數(shù)的功能更明確，只有功能明確，才能明確的測試;能讓你的接口更合理，因為不合理的話，依賴關(guān)系太多或者接口太復(fù)雜，測試寫起來會很麻煩……
最重要的是，以后你改了什么東西，破壞了現(xiàn)在的接口，可以馬上知道。不會在發(fā)版本的最后一天，才有人告訴你：“這個功能以前是好的，我們已經(jīng)好幾天沒有重新測試了?，F(xiàn)在壞了，不知道問題在哪里。全體加班吧!”
不花什么時間，還有不少好處。免費午餐，為什么不試試呢?
對于想不明白的事情總是喜歡刨根問底
世上的事，皆有因果。軟件也是一樣，出現(xiàn)一個bug，可以說一定有原因，只能說有時我們不知道原因，但是不能說，沒有原因。從這一點看，測試和醫(yī)生有很大的相似之處(都是根據(jù)一些表面的癥狀，查找內(nèi)部的原因，然后給出解決方案)。
測試人員堅信世上沒有無因之果，當(dāng)我們遇到bug的時候，總要考慮怎么找出bug的原因，如果找不到，寢食難安。在生活里，碰到想不明白的事情，也總是習(xí)慣性的刨根問底，一定要獲得一個答案。最常見的一個場景，就是當(dāng)一樣?xùn)|西找不到了，我便發(fā)了瘋一般的找，完全投入進(jìn)去，不斷的回憶和推理，一定要把它找到，真的是到了廢寢忘食的程度，我的老媽老婆也是哭笑不得。
對自己和身邊的事物要求盡善盡美
測試工作也是一項追求完美的工作，當(dāng)我們宣布一個軟件“合格”的時候，可以說幾乎考慮了所有的可能性，證明了它沒有問題?？杉词惯@樣，還是會有我們考慮不到的情況，會出現(xiàn)bug，于是，我們會繼續(xù)完善測試方案，讓軟件更完美。
我們最喜歡看的東西，就是一張全部標(biāo)著“pass”的測試清單。如果里面有一個紅色的“fail”，就會覺得渾身不爽。漸漸地，我們變成了完美主義者，對身邊的人和物，都希望完美。
但是這世上的事情和人，都不是盡善盡美的，所以完美主義者活的會很辛苦。比如我家里的電腦，為了保證電腦軟件系統(tǒng)“完美”的工作，我經(jīng)常的重裝xp系統(tǒng)。只要系統(tǒng)出了點問題，其實遠(yuǎn)不到需要重裝的程度，但是我覺得不爽，干脆，重裝!我老婆都煩了：你怎么又在裝系統(tǒng)。這個毛病現(xiàn)在已經(jīng)好多了，我已經(jīng)堅持半年沒重裝系統(tǒng)了。這是不是強(qiáng)迫癥啊?
寫了這么多，大家是不是覺得我似乎已經(jīng)“病入膏肓”了。其實我寫的時候很開心，一點沒有覺得壓力，反而很輕松。有時想想這些事情，著實有趣，隨它去吧。
一方面，他們沒有cruise control之類的工具，甚至連daily build都不見得有，單元測試也不上傳到版本控制里。這樣做測試的意義就不大了。
另一方面，他好像把單元測試和接收測試(acceptance testing)、集成測試(integration testing)搞混淆了。因為他說，業(yè)務(wù)邏輯很復(fù)雜，測試數(shù)據(jù)不好做……
單元測試，顧名思義，就是對一個單元的測試(好像什么也沒說)。通常這個單元是指(類的成員)函數(shù)，或者函數(shù)的一個功能。
每個測試就只針對一點，不涉及其余，還是比較好寫的。函數(shù)的輸入是什么，(對象當(dāng)時的狀態(tài)是什么)，得到的輸出是什么;有幾種不同的情況……
我感覺，同一個函數(shù)的單元測試加在一起，就相當(dāng)于這個函數(shù)的詳細(xì)設(shè)計文檔。自然，設(shè)計文檔應(yīng)該在實現(xiàn)之前寫，而不是實現(xiàn)了以后再補(bǔ)。
和傳統(tǒng)開發(fā)方法里的詳細(xì)設(shè)計不同，寫一個單元測試，就寫一段代碼讓它通過。這樣你就不需要在實現(xiàn)的時候，再去讀文檔，再去回憶當(dāng)時是怎么想的，能提高效率;更重要的是，這個“文檔”是能反復(fù)運(yùn)行的，可以保證和實現(xiàn)的一致性。
如果你的開發(fā)環(huán)境配置的好，照我的經(jīng)驗，寫單元測試再寫代碼，和直接寫代碼相比，不會多花什么時間。
編碼過程中有相當(dāng)一部分時間是花在想清楚下一步要做什么上，想到了就把它寫成一個測試。這么做是要花一點點時間，不過能幫你盡快驗證下面的實現(xiàn)跟你現(xiàn)在想的一致;能幫你理清思路，到底有幾種情況需要考慮，就寫幾個測試;能讓函數(shù)的功能更明確，只有功能明確，才能明確的測試;能讓你的接口更合理，因為不合理的話，依賴關(guān)系太多或者接口太復(fù)雜，測試寫起來會很麻煩……
最重要的是，以后你改了什么東西，破壞了現(xiàn)在的接口，可以馬上知道。不會在發(fā)版本的最后一天，才有人告訴你：“這個功能以前是好的，我們已經(jīng)好幾天沒有重新測試了?，F(xiàn)在壞了，不知道問題在哪里。全體加班吧!”
不花什么時間，還有不少好處。免費午餐，為什么不試試呢?
對于想不明白的事情總是喜歡刨根問底
世上的事，皆有因果。軟件也是一樣，出現(xiàn)一個bug，可以說一定有原因，只能說有時我們不知道原因，但是不能說，沒有原因。從這一點看，測試和醫(yī)生有很大的相似之處(都是根據(jù)一些表面的癥狀，查找內(nèi)部的原因，然后給出解決方案)。
測試人員堅信世上沒有無因之果，當(dāng)我們遇到bug的時候，總要考慮怎么找出bug的原因，如果找不到，寢食難安。在生活里，碰到想不明白的事情，也總是習(xí)慣性的刨根問底，一定要獲得一個答案。最常見的一個場景，就是當(dāng)一樣?xùn)|西找不到了，我便發(fā)了瘋一般的找，完全投入進(jìn)去，不斷的回憶和推理，一定要把它找到，真的是到了廢寢忘食的程度，我的老媽老婆也是哭笑不得。
對自己和身邊的事物要求盡善盡美
測試工作也是一項追求完美的工作，當(dāng)我們宣布一個軟件“合格”的時候，可以說幾乎考慮了所有的可能性，證明了它沒有問題?？杉词惯@樣，還是會有我們考慮不到的情況，會出現(xiàn)bug，于是，我們會繼續(xù)完善測試方案，讓軟件更完美。
我們最喜歡看的東西，就是一張全部標(biāo)著“pass”的測試清單。如果里面有一個紅色的“fail”，就會覺得渾身不爽。漸漸地，我們變成了完美主義者，對身邊的人和物，都希望完美。
但是這世上的事情和人，都不是盡善盡美的，所以完美主義者活的會很辛苦。比如我家里的電腦，為了保證電腦軟件系統(tǒng)“完美”的工作，我經(jīng)常的重裝xp系統(tǒng)。只要系統(tǒng)出了點問題，其實遠(yuǎn)不到需要重裝的程度，但是我覺得不爽，干脆，重裝!我老婆都煩了：你怎么又在裝系統(tǒng)。這個毛病現(xiàn)在已經(jīng)好多了，我已經(jīng)堅持半年沒重裝系統(tǒng)了。這是不是強(qiáng)迫癥啊?
寫了這么多，大家是不是覺得我似乎已經(jīng)“病入膏肓”了。其實我寫的時候很開心，一點沒有覺得壓力，反而很輕松。有時想想這些事情，著實有趣，隨它去吧。