在 Ruby 的測試中輕鬆做到參數化測試
Apr 21, 2020
只是個小短篇記錄最近的反思和實際測試能力的應用。
上下文（Context） 最近的兩份工作都主要是在 Rails 開發，兩份工作都是高度重視測試的團隊，不過在實際的場景不太相同一樣，前一份工作主要已經引入或者開發了改善開發效率的工具，而後者是已經有一定許多既存的測試，也有一定複雜度的架構，不過許多開發工具都還在比較早期的階段，比較沒有著墨過多在開發流程的部分。
遇到的問題 參數化測試是撰寫測試案例中非常好用的一種技巧，通常的使用情境在於測試的對象和步驟是一致的，但是輸入和輸出是不同的。
舉例來說，我們有一個類別如下。
class OpGreater attr_reader :op1, :op2 def initialize(op1, op2) @op1 = op1 @op2 = op2 end def call op1 > op2 end end 測試案例可以如下
...
➦ [閱讀心得] OKR：做最重要的事
Feb 29, 2020
上一份工作中因緣際會必須負責一個小團隊，加上自己時不時會閱讀一下商管的文章或書籍，對於管理的知識一直都有在學習。知道這本「OKR：做最重要的事」其實是兩年前的事情，去年公司也在實務上正式導入，也因次順著把這本書給唸了一次，多了解它一點也比較能知道引領者原本的設定，比較不會偏離 Andrew Grove 以及 John Doerr 的理論和實踐。
而即便有倖存者偏差的可能，這套方法也還是有不錯的參考價值，帶來管理方法裡不同的思考方向和實踐。
它是一種目標管理方法 OKR 是 Objective, Key Results 的縮寫，中文翻譯是－目標及關鍵結果。它是一套近年來流行的目標管理架構，與我們比較耳熟的 KPI（Key Performance Indicator）同屬目標管理的範疇；但是 OKR 對於目標的設定、驗證和執行是不同的。這篇心得沒有要細部探討兩者的不同，除了書面資料，我也沒辦法給出比較確切的差異，然後我相信大家看了還是會一頭霧水，因為我當初看的時候也是⋯更不用說還有什麼 MBO 之類的了。
既然都是目標管理，那到底有什麼不同？
首先我覺得是賦權。傳統的經營管理中，目標一般是由上往下佈達，在執行端的人基本上只有接受決策和執行命令。在 OKR 的架構中則是鼓勵組織中公開討論和分享以及訂定各自現在以及未來的目標；不管這個目標是來自某一個同功能的團隊內部（內部需求，由下往上），或者是在組織末端分屬不同功能團隊的成員一致想達成的（橫向整合需求，由下往上），或是公司管理階層想要達成的目標（由上往下）；然而不管是哪一種，被選擇的 OKR 都是公開透明的，即使是公司最高負責人的個人 OKR 也是。其背後的想法在於透明化組織前進的方向，來讓群體盡力在同一個方向上努力，已達到最大的效果。
...
➦ [閱讀筆記] 單元測試的藝術 Part II
Feb 23, 2020
單元測試的藝術 - 核心技術篇 (Ch3 - Ch6) 回顧 工作單元的可見最終結果有三。
有回傳值。 系統可見的狀態或行為改變。 呼叫不受測試控制的第三方系統。 測試的種類
單元測試 整合測試 (New) 互動測試 互動測試－ 針對物件如何向其他物件發送訊息的測試。用於測試工作單元的最終結果是與其他系統互動的時候，例如，發送 Log。
測試的藝術在於 在合適的地方加入或使用一個中介層封裝原本的呼叫行為，藉此可以模擬中介層行為進而測試工作單元。 測試程式面臨的挑戰 受測單元的外部依賴（External Dependency） 無法控制的外部依賴會造成“抑制測試”的現象。
抑制測試（test-inhibiting）— 當程式碼依賴於某個外部資源，即使邏輯是完全正確的，但這種依賴仍可能造成測試失敗。
例如，當工作單元的行爲是需要讀取系統中的設定檔案或者網路服務來決定。
測試時常用到的技術 Fake 假物件 假物件是通用名詞，可能會是 Stub 也可能會是 Mock，依照使用情境會有相對應的行為。
...
➦ [閱讀筆記] 單元測試的藝術 Part I
Feb 23, 2020
單元測試的藝術 - 入門篇 (Ch1 & Ch2) 定義們 被測試系統 SUT（System Under Test） 被測試程式所測試的對象，可以是函數，可以是類別，可以是一個複雜的元件，也可以是一個軟體。 一般來說
工作單元、使用案例 Use Case 從呼叫系統的一個公開方法，到產生一個測試可見最終結果，在期間這個系統所發生的行為統稱為一個工作單元。
可見的最終結果可以是
回傳值（如果公開方法有回傳值的話） 系統可見的狀態或行為改變，不需要查詢私有狀態就能取得。 呼叫一個不受測試所控制的第三方系統，這個第三方系統不回傳任何值或者回傳值不被系統使用。 單元測試 Unit Test 一個單元測試是一段自動化的程式碼，這段程式會呼叫被測試的工作單元，之後對這個單元的最終結果的某些假設或期望進行驗證。
特質
執行起來快速。可靠、易讀、並且很容易維護。只要產品程式碼不發生變化，單元測試的執行結果是穩定一致的。
自動化的，且可以被重複執行的。 容易被實現。 到第二天還有存在意義，非臨時性的。 任何人都可以按個按鈕執行它。 執行速度很快。 執行結果一致。 應該要能完全掌控受測單元。 完全被隔離的，獨立於其他測試。 如果執行結果失敗，能夠簡單清楚的呈現期望為何以及發生問題的原因在哪。 整合測試 Integration Test 對一個工作單元進行測試，而這個測試對被測試的單元並沒有完全的控制，而是使用該單元一個或多個真實依賴的相依物件，例如時間、網路、資料庫、執行緒或亂數產生器等等。
...
➦ Trapped by Ruby Operators Precedence
Feb 22, 2020
Let the story begin I started to work on a new production code repository, and I could tell my productivity degraded for almost 7 workdays. But this was not because of my lack of domain knowledge in the new production code nor the new development environment and configuration.
...
➦ 