當我們有了關鍵案例（Key Examples）後，規格已經相對的明確，如果還能夠被自動化測試的話，是不是一件更好的事情呢？我們可以利用 Cucumber 來實踐 E2E Testing（端對端測試）讓我們模擬使用者實際操作來驗證規格的完善。

最近工作上以及私下跟朋友討論時，剛好都遇到了 Null（不存在）類型的處理，通常我不會特別去在意這件事情，然而近年讀了一些關於 Null 的文章後（如：The worst mistake of computer science）對於這件事情的看法有不少改觀。

我們在工作的過程中大多是以需求（Requirement）當基準來進行開發的，然而要盡可能的接近規格（Specification）就需要多花一些力氣。大多數人其實下意識的都有實行這個動作，因為透過大量的溝通還是可以取得足夠的資訊，然而這樣做的效率跟成功率不一定足夠。

我們想要去「實踐」一個想法，大多數情況都是「做看看」來驗證是否可以成功，然而在這個過程中，我們需要有多少次的失敗呢？同時，為什麼有些人總是很容易的就成功，而自己卻總是沒辦法順利前進呢？

mruby 透過編譯器（Compiler，通常是 mrbc）編譯後，會產生 mrb 格式的二進位檔案，這個檔案的格式被稱作 RITE 如果要運行編譯後的 mruby 程式碼，就需要能夠解析並且讀取。

2021 年底，我開始思考什麼是「開心地寫程式」這件事情，如果單純是興趣也不跟其他人合作，那麼是很容易的。然而，如果想要將寫程式作為工作，就一定會面臨到跟其他人協力的問題，很多時候會是我們抱怨「寫這段程式的人在想什麼」的原因。

也就是說，如果能讓眾多的初階開發者（Junior Developer）寫出更好的程式，那麼對所有人來說都能夠更加專注在享受寫程式的過程。

端午節連假利用空檔轉換心情時，把去年重寫後沒有完成的玩具再次拿出來挑戰，剛好在處理一對多的關聯時發現 Domain-Driven Design（領域驅動設計） 中對於 Aggregate（聚合）要作為統一操作其關聯的 Entity（實體）的原因。

最近在工作中對專案套用 google/wire 來處理依賴注入（DI，Dependency Injection）時，發現有非常多小細節需要注意。大多數語言其實都會碰到這類問題，然而 wire 的設計沒有採用大多數框架會提供的控制反轉（IoC，Inverse of Control）機制來處理，反而讓很多過去沒有考慮的狀況浮現出來。

過去一年花了不少心力在學習調整心理狀態，也慢慢的能夠理解「活在當下」的概念想要傳達什麼，同樣的概念也讓我想到了學習敏捷開發中的一些技巧，意外的能讓在寫程式的過程中更順利。

經過接近半年的連載，最後我們要來聊一下如何「加入測試」的問題，雖然我們了解到了各種撰寫測試的技巧，但往往我們是卡在不知道從何開始測試，因此跟大家分享一些實用的小技巧。