Coding | Test Case 值得寫嗎?
MacauYeah・2023-11-02很多做軟件開發的朋友，其實都會聽過Testdriven的開發模式。就像Scrum一樣，名氣很高，但試過的人很少。為何會這樣呢？筆者認為，並非開發者懶，而是編寫Test Case的難度真的高。對比開發程式本身的成本，寫Test Case的時間學習成本一樣高。 造成這些高成本的原因很多。一來是因為開發者並不像過往一樣，慢慢從零寫程式，一般都應用Framework去預構建一些東西，例如打包Database connection pool，Dependency injection。Framework是好用的，但就令你要模擬Mock up特定資源，變得越來越複雜。所以一般中、小型開發，都鮮有人懂得做Test Case除了大神獨立開發者外。筆者對於Spring boot等Framework，都摸索了很久，才能模擬一些特定資源。但Framework一更新，就很多部份都要重寫。所以筆者沒有很強調要做Test Case，因為成本認真大。 最近，在摸清一些test case 基本concept後，筆者又重新開始嘗試編寫test case。以下假設用的是object oriented programming 在開發自己的class，為每個public function，都寫test case。很多IDE, 都有提供相關自動生成test case function signature的功能（就是為你的目標function，起一個只有外框的test function。）vscode雖然不是原生支援java，但只安裝基本的java test package，就可以達到同樣效果。 在不依靠framework的情況下，自己class要『引用』的其他class object，不要經過自己使用new來生成object。全部經set function來傳入你要引用的class object。除非你的class是作為Factory Pattern（工商模式）生產某些object，不然你就不會再有new字眼。 在為自己class編寫test case時，就會可以模擬被『引用』Object的行為。這個object在傳統上可以使用oop中的interface類型來達到模擬又不會影響到原結構的做法。實在不想做interface，java還可以用mackito 這個libraray來硬改Object的行為。 同理，自己class要『引用』一些外部資源，那些設定資源的config，都應該要set function傳入。這樣你在test case中才能起一個臨時的模擬外部資源。 在不使用framework的情況，要全數去自行模擬，當然很痛苦，但至少你可以做一些很簡單的測試。 在使用framework的情況下，還有些教學都是教你mockito繼續模疑。但這會是很痛苦的，因為這樣叫做unit test，單元測試，你要模擬所有東西。在折衷的情況下，應該底層元件做unit test，但上層的元件就做integration test，整合測試。 在做integration test時，就差不多等同使用framework行起部份或必要的資源。而那些必要資源，可能指是的database service, network service。我們可以在test case中設立不同的config，從而把framework指向一些備用資源。 Database好貴，腦細不會付錢set up多一套，自己電腦不夠強，也不能跑起多個開發用Database。好在還有h2 database可以幫你，它是memory可以操作的。只要你的framework支緩就好。在初次使用Framework時，你總會覺得為何Database層要設得這些抽像，其實為的就是讓你可以隨時換Database。不論做測試還是做移植，都會少很多問題。 模擬Network service還是沒有銀彈，要麼就mockito硬改行為，要麼就是提供一套測試用service。筆者曾經為模擬別人的Network Http API，也花了相當時間自己建立dummy server，提供模擬效果。無論dummy的效果有多假，有多局限，例如if id == 1，always return true，也是有一定價值。當你做source code refactoring （重構），又或是做framework升級時，還是讓你可以安心一點。
熊神進・2018-12-29
80後愛旅行✈️・2023-07-31
Lifemagtechie・2020-12-17
OHChance 旅遊誌・2015-10-09
Ping・2017-06-25
LifeMag Editor・2015-09-21
澳門生活圈・2018-11-22
澳門優惠・2020-02-28
Lifemagfoodie・2021-02-09
喜悅子&悅子服務・2020-09-18
Cheers!・2018-05-29