iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 29
1
Software Development

【Unit Test】Unit Test with C#系列 第 29

【Day 29】初談Unit test程式撰寫架構

一開始的寫小程式,覺得能寫出來就很厲害。持續開發後,程式碼越寫越多,之後越來越難懂,所以就開始研究要如何快速的閱讀和理解程式。發覺到,有個完整的程式架構可以讓自己或是他人快速的理解、閱讀這份程式碼,輕輕鬆鬆得到程式資訊。
Unit test也是相同的道理,此部分將會參考書籍的第七章進行分享。


在前面有討論到要如何命名以及程式碼的編排意義,這是一個初步的檢視程式碼方法。當檔案多的時候,或是結構複雜化,僅使用命名方式是無法滿足Unit test快速地了解測試項目的需求。

首先把要運作的程式碼和Unit test分開,這樣可以清楚的看出來要做的測試,以及測試對象為何。例如:

---NumberCompare
 |
  -Unit test

這樣就有簡易的兩個資料夾。
接著在資料夾內,我們可以放置一般的程式碼,或是放在不同的項目中,擁有不同的命名空間。
例如:

---NumberCompare
 |
  -Unit test
   |
   |
    -LogAn.Test.UnitTest (此為放在項目中,有自己的命名空間)
   |
    -LogAnA.cs
    -LogAnB.cs
    -LogAnC.cs....

這兩種方式,主要還是看個人習慣。此部分作者沒有提到,不過我個人會偏向有相同的命名空間,因為這樣要找類似的功能,直接去裡面找就好,不用一個一個看去猜其位置。
不過作者有特別提到,需要注意的是要把「單元測試」、「集成測試」。如同先前所說,「單元、測試」主要是使用於基本的架構,像是買了就走的路邊攤行。不過「集成測試」就是不一樣,簡單來說,就是把很多的單元測試整合在一起,把很多功能整合在一起。
因為有時候單獨執行Unit test,會發生不可預期的錯誤,而這樣的錯誤發生在之前如果有先使用「集成測試」,可以確定環境之前是可以的,所以當程式碼要測試時可以先檢查集成測試。當發生一些系統配置(或是需求)可以提前知道。
為什麼不使用單元測試呢?因為有時候可能網路延期,或是其他系統被擲原因,而導致收不到資料,在此狀況下就會發生錯誤。所以要清楚的知道狀況,所以要先使用「集成測試」。
而集成測試和單元測試是要如何配置位置呢?這邊作者建議是使用各別管理方式,希望可以使用不同的資料夾進行區分,讓大家可以可以快速地執行「單元測試」和「集成測試」,可以更快速地鎖定問題。
作者更提出更進階的做法:使用綠色安全區。就是讓使用者廁時時可以執行此區域,當拿到新的程式碼的時候執行此綠色安全區,當成功的時候符合預期,當有錯誤時,之後將再鎖定為題位置,再逐步去debug。


後記:
當使用GO和Python後,覺得使用既定的格式可以快速的閱讀程式。真的可以減少很多時間。
但是自己切割的仍不是很好,但是網路的高手們都是有大量開發經驗者,寫出一個漂亮的程式,希望自己也能朝這個方向邁進,建立一個漂亮的程式專案!


上一篇
【Day 28】狀況雜談3-Multi thread 多執行緒(使用Queue)
下一篇
【Day 30】淺談:編寫可靠的測試
系列文
【Unit Test】Unit Test with C#31

尚未有邦友留言

立即登入留言