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