一直搞不懂unit test要從何做起、好處何在 最近處理比較敏感的資料 開始試著寫unit test 終於慢慢知道在MVC架構中 替Model寫測試的好處何在 想跟大家分享一下我的心得 好讀版 http://blog.turn.tw/?p=110 ------------------------------- 在web的MVC架構中，我們開發時本來就不斷在test。 你一直對網頁按重新整理就是在test 你在剛寫好的頁面上輸入一些測資然後按確定，也是在test你的controller或model 也就是testing的工作你其實一直都在做。 而MVC架構中的Model特別難處理，因為Model的行為很難測。 在資料到達Model之前，會先經過View、Controller， 所以你會來回狂測，想確定bug到底在 哪。 是jQuery在抓網頁元素的value時抓錯？是JavaScript相關的code有bug？是html的某個 form name打錯？是Controller拿到form POST的值時做了變數型態轉換？ 是Controller裡面變數名稱打錯？是丟變數給Model時順序丟錯？ 還是Model裡面有bug？ 反覆跑完以上流程抓出bug就算了，偏偏並非每個功能都是直接在網頁上key完資料就丟給 Model。 結果光是想丟測資給Model就很麻煩。尤其你修好一個method常會想確認其他method有沒有 因此壞掉。 行為單純的Model就算了，以上過程還不會花掉太多時間。 複雜一點的 Model真的是debug到會在電腦前大罵髒話。 針對Model寫單元測試等於在開發Controller跟View前，先把Model弄得很強壯。 為了搞清楚自己的Model有多健康，你會寫好幾個test、丟好幾筆測資。 加上為了要讓model能被test，你會來回去修改、把model寫的更模組化、更testable 、 讓使用Model的人用得更愉快。 然後使用Model的人就是你自己。 所以unit test寫完、測完，你再寫controller跟view的時候就快樂到爆。 因為你知道寫Model的那傢伙很猛、把它寫得很強悍（亂丟資料也不會怎樣， 那個Model會丟Exception、會丟error、會吐訊息， 反正Model會強力守住最後一道關卡 資料庫絕對不會爛掉。） 所以你Controller跟View就可以輕鬆寫，頂多就是使用者key錯資 料會看到exception或是一些怪怪的錯誤訊息，絕對不會有資料庫存到壞掉的資料或是資料 一致性的問題出現。 開發上出現bug時，你也可以確定是controller或是view的資料處理出錯，千錯萬錯絕不是 Model的錯。（那真的是Model有bug怎麼辦？回去再寫幾個test抓bug，然後修好就行囉） 然後我認為，單元測試也不需要把所有可能的測資、全部使用情境都測過。 每個method隨便寫幾個最笨的testing就很夠了 ，通常有bug就是return value完全跟預期不一樣。 寫幾個笨testing就夠抓出一堆麻煩了。 像是： 資料庫某table在新增完有沒有多一筆 各欄位金額加總有沒有等於總金額欄位 那個要抓10筆資料的method最後抓到的是不是10筆 亂丟變數給某method有沒有吐Exception 只測試這些夠混吧？但是最常搞出來的bug就是這麼單純而已。 當這些testing都跑過了，你的Model已經非常頭好壯壯了，超健康。 眼看自己動手去挑戰自 己的Model，最後還全部過關，絕對會信心UP、UP。處理複雜的Model時， 將省下很多時間。 （就算不寫單元測試，你也是用瀏覽器東測西測、花時間抓bug不是嗎？） 好，做個整理。 時機 某Model光用想就覺得頭痛，開發起來你覺得很沒安全感 好處 讓你跳出開發者的角度，從使用者的角度去看這些method好不好用、 直不直覺，因此能寫 出更出色（reusability, maintainability, scalability）的Model 每次改完某method，都能立刻檢查其他的method有沒有被搞壞 更好抓bug（寫testing時會在Model狂抓bug。之後寫controller/view時， 你會知道bug都在controller/view裡面，不用跳來跳去檢查一堆code） --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.167.4.247