假設今天我們要測試一個自己寫的書店購物車程式，
我們該如何寫測試？

首先，購物車程式碼可能是這樣：

開了一個書店

每個訂單的內容

每本書的物件資訊

根據3A原則：
Arrange: 確定測試目標範圍
Act: 呼叫
Assert: 驗證結果

我們乍看之下這個書店的程式正常執行沒什麼問題，但：

書本的價錢如果輸入錯誤的範圍，就會讓書店的總價跟著錯誤。

但如果這整個書店的內容，都要撰寫測試，
會稍嫌複雜，因此筆者想把功能先分開來看。

這個範例筆者沒有特別花心思設計，
一個書本設計上來說，當然不允許輸入錯誤的價錢，
但先排除設定價錢時就應該跳出錯誤通知的設計範疇來看，
假設我們將輸入負數的價錢統一預設為0元，
因此可以初步的確保這個書店至少不會賠錢。

書本setPrice的地方加了一個修正判斷

因此我們可以寫個測試程式，先確保書本的assign value沒有問題。

因此，原本錯誤的test code也因此可以過了，如此可以初步的確保書局的價錢不會出錯。

在這個範例裡面，
確定我們要測的就是書店的總價(Arrange)，
撰寫測試程式呼叫訂單總價(Act)，
以及確定我們預期的結果是否是程式執行的結果(assert)，
就完成了一次最簡單的測試。

p.s. 這個範例有許多的問題，越想越不對勁…
如：建構子不該放判斷式，不該給錯誤的價錢投進系統正常執行...
但這些不是這個範例要表達的意思~請勿誤會~~ 

接著檢討這個方案有無符合FIRST：
Fast : 快速驗證 (有)
Independent : 受測試的程式獨立執行 (獨立)
Repeatable : 測試執行結果無誤差 (無誤差)
Self-Validating : 自我驗證 (嗯)
Timely : 測試碼要比production code 早完成 (不太正確)

因此這次的練習不符合TDD的FIRST原則。

最後，這份練習有無實踐 SOLID呢？
S : Single Responsibility Principle (單一職責原則)
O : Open Closed Principle (開放封閉原則)
L : Liskov Substitution Principle (里氏替換原則) or 
  Least Knowledge Principle (最小知識原則)
I : Interface Segregation Principle (介面隔離原則)
D : Dependency Inversion Principle (依賴反轉原則)
就交給讀者評論了。

測試是要融合到目前實作的程式上，才會慢慢熟悉，
這些名詞如有不懂的地方都可以上網Google學習，
寫測試程式或使用TDD開發，都不會是可以一步到位的，
每次的撰寫程式中刻意的練習，就會慢慢的進步，
測試的章節也就講到今天為止，
測試更深入的部分就讓讀者跟筆者一起自我學習吧！
今天的分享就到這裡，感謝各位。

本文同步發表在Medium，連結在此。