前言 - Rails 開發實踐
2021 年底,我開始思考什麼是「開心地寫程式」這件事情,如果單純是興趣也不跟其他人合作,那麼是很容易的。然而,如果想要將寫程式作為工作,就一定會面臨到跟其他人協力的問題,很多時候會是我們抱怨「寫這段程式的人在想什麼」的原因。
也就是說,如果能讓眾多的初階開發者(Junior Developer)寫出更好的程式,那麼對所有人來說都能夠更加專注在享受寫程式的過程。
Pager 1
2021 年底,我開始思考什麼是「開心地寫程式」這件事情,如果單純是興趣也不跟其他人合作,那麼是很容易的。然而,如果想要將寫程式作為工作,就一定會面臨到跟其他人協力的問題,很多時候會是我們抱怨「寫這段程式的人在想什麼」的原因。
也就是說,如果能讓眾多的初階開發者(Junior Developer)寫出更好的程式,那麼對所有人來說都能夠更加專注在享受寫程式的過程。
我們想要去「實踐」一個想法,大多數情況都是「做看看」來驗證是否可以成功,然而在這個過程中,我們需要有多少次的失敗呢?同時,為什麼有些人總是很容易的就成功,而自己卻總是沒辦法順利前進呢?
我們在工作的過程中大多是以需求(Requirement)當基準來進行開發的,然而要盡可能的接近規格(Specification)就需要多花一些力氣。大多數人其實下意識的都有實行這個動作,因為透過大量的溝通還是可以取得足夠的資訊,然而這樣做的效率跟成功率不一定足夠。
當我們有了關鍵案例(Key Examples)後,規格已經相對的明確,如果還能夠被自動化測試的話,是不是一件更好的事情呢?我們可以利用 Cucumber 來實踐 E2E Testing(端對端測試)讓我們模擬使用者實際操作來驗證規格的完善。
通過規格的分析我們準備好了 E2E Testing 的文件,以及對應的步驟實現,然而在這個狀態下是無法順利通過測試的,因此我們需要進行一些實作。在只有一條測試的狀況下,我們可以用非常簡單的方法通過這個測試。
過去我在寫測試的時候經常會有「這裡該測試嗎?」的疑問,然而這個問題其實可以從另一個角度思考,那就是「這些測試組以完善規則嗎?」去想,以我們第一個 E2E Testing 的測試作為例子,雖然可以通過測試,然而實作的內容只是一些假資料,我們需要用另一條測試從其他角度去驗證,讓實作最終變成我們預期的樣子。
你有想過資料(Data)和資訊(Information)的差異嗎?在軟體開發的過程中,我們做的通常被叫做「資訊系統」然而大多數情況,我們很可能只是單純的把資料放到一個程序裡面,然後對這些資料做了一些調整,中間並沒有「資訊」的概念在裡面。
因為我們還沒有完善所有的邏輯,因此儲存到資料庫將狀態持久化的機制可以先不處理,接下來我們需要建構不同的「測試資料」讓訂閱狀態有不同的呈現,而不是像現在這樣只有寫死的訊息。
有一些情況,並不會在規格上被描述出來,我們該去測試嗎?舉例來說,目前的實作在建立訂閱的時候,並不會檢查「重複訂閱」的狀況,雖然在介面上使用者是無法進行這樣的操作,我們應該去測試這樣的情況嗎?
我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription
的例外,然而這種情況是無法在驗收測試的狀況下被重現出來,因為使用者無法在正常狀況做到這件事情,在這種狀況下單元測試就非常適合。