要求涵蓋率啥的，老實說已經聽到膩了
老實說這種東西用意很好，可是工具不足，時間不足

我TMD直接問了
你是要滿滿的Unit Test但程式還在開發，還是大量已完成的程式搭上少量必要的單元測試

沒有兩者都要的選項，我們不會分身，同一時間只能處理一件事情
按我以閱讀全文>>




不過老實說以上全部都算了，因為今天看到史上最扯的一件事情

現在已經進化到單支API Unit Test 測了所有經過這條API的所有Function和檔案
你是單元測試中毒還是怎樣?
所以整合測試和串接測試外帶一堆阿薩布盧的測試都要搞成單元測試嗎?

最慘的是這些東西還是phpunit這種殘缺產物的東西

程式固然需要品質，但一味的盲目追求完美品質，遠遠不如逐漸改善

-----------------------------------------------------------------------------------

實戰怎麼使用Unit Test

我直接明白地跟你說，我unit test裡面 assert少到一個根本不太想寫的地步
甚至還有沒有assert的
為什麼?有用的不是assert，而是print_r

差在哪?我的unit test可以極短時間開發，可以馬上看出問題(這是真正對開發者有效益的地方，沒別的了)，想當全自動所有狀況測式的作法絕對不行，而且寫很久還會有一大堆執行上問題要De單元測試的Bug(光是聽到de unit test bug這個動作，稍微有點程度大概都知道這很荒謬

你們那些一味追求自動化的中毒者，有判別到所有狀況了嗎?能因應改版馬上改出相對應的複雜邏輯嗎?最重要的你花了多少時間在"解決phpunit很難開發"這件事上

甚至想把它當成auto full test，這種東西真有這麼自動，這麼好用，早就變成主流了
因為她一點也不自動，也無法判斷所有狀況，更無法偵測未知錯誤

再者，可能會有人想反駁
"我利用switch case慢慢寫出模擬所有可能發生的狀況後，也測出問題了，你看，單元測試有用的吧"

抱歉，單元測試是有用，但你寫這麼多根本白寫的
因為手動測一次可以比你快四倍以上的速度發現問題，花時間開發這些判斷句，都可以解掉好多BUG了
再者寫這麼多常常只要修掉一個小BUG，未來都沒有機會出問題了

最後，單元測試常常不是日常執行出問題報出來的BUG
這些單元測試中毒者，大概想都沒想到BUG只會發生在自己沒寫到的判斷
或者如果有合作，或有客戶，合作者和使用者報過來的BUG還比較精確

為什麼有必要把單元測試搞到這麼複雜，還根本測不出問題來?
還有那些堅持要先寫單元測試的，為什麼都沒有自己寫過就開始下規定?(寫CASE，不是寫EXAMPLE)

甚至還有看到非常好氣又好笑的狀況
堅持先做Unit Test，然後實際撰寫發現，阿，這樣架構不行，恩我回去先改Unit Test
改完然後再回去撰寫本體，恩不行這樣還是要修Unit Test
然後寫完發現程式與邏輯又有優化，再度改了Unit Test
然後發現程式有些邏輯如果按想法直接做很難Unit Test，我要配合Unit Test改寫
搞來搞去，程式握好久還出不來，最後被追殺了，恩我放棄Unit Test直接趕工了

為什麼會發生上面那種極度搞笑的狀況
原因只有一個，你們根本沒搞懂這東西怎麼用

真正用法是做完一個確定進度以後，寫一個可以確認自己剛寫的東西是否能RUN的
方法?print_r var_dump echo絕對不是assert
這東西是Run Test，我程式不管怎麼改，我都是看執行結果判斷我寫的對不對
而不是花一堆時間讓程式幫你判斷，然後還很搞笑的判斷不出來，最後只好硬著頭皮補
var_dump然後測完又刪除，然後發現又有問題，又補var_dump然後測完又刪除
(請思考以下問題:
1.寫這麼多判斷式，有讓你開發變快嗎?
2.寫這麼多判斷式，一旦真的出問題，你是不是還是要var_dump看錯在哪
3.想要單靠assert就抓到bug點在哪究竟應該怎麼寫判斷式?
4.寫這麼多判斷式，抓到的問題是什麼狀況才會產生?)

會有以上問題的產生，主因是我們的程式本身就沒有那麼簡單
畢竟要function(a){return a+1}也不會特地找你來寫了

我同意極簡單的程序可以寫assert，因為這樣就能確定他有沒有運作
但如果過於複雜，請直接全印出來，即使assert也只確認型別(而且不要去判斷是不是空值)

程式不該喧賓奪主，單元測試永遠是附屬的產物

單元測試再怎麼重要，也沒有本體能正常運作重要
涵蓋率再怎麼重要，也沒有本體功能完整性重要

程式先有實用原因才有理論
理論再怎麼重要，也沒有程式實用重要
單純為了理論而去修正程式寫法根本是本末倒置