[TDD] leet code 219. Contains Du

用 TDD 來練習完成 leet code 的第 219 題，題目描述如下。

Given an array of integers and an integerk, find out whether there are two distinct indicesiandjin the array such thatnums[i] = nums[j]and theabsolutedifference betweeniandjis at mostk.

題目解釋：給一個int[] nums，以及一正整數k，如果存在著 i 與 j 使得nums[i] = nums[j]，且|i-j|<= k，則回傳true。若不然，則回傳 false。

這篇文章要透過 TDD 的方式，來解釋我的思路跟程式碼演進過程。

第一個紅燈，k = 0，應回傳 false

這個測試案例代表的用意，是先用最簡短的路徑，處理實際的商業邏輯，透過測試驅動產生出來產品程式碼的 class 名稱、function 名稱、參數名稱與型別、回傳的型別。

測試程式碼如下：

第一個紅燈

產品程式碼，是由測試程式碼透過 Visual Studio 產生的 class 與 function，內容如下：

從測試程式所產生的產品程式碼的殼

用最簡單的程式碼，符合測試案例關鍵邏輯，迅速通過第一個紅燈，得到綠燈

產品程式碼的處理：針對 k = 0 的情況，return false;

透過 baby step 得到綠燈

新增一個測試案例， nums = {5,5}, k = 1, return true;

這個測試案例代表的用意，是為了找到相同數字，回傳 true。

測試程式碼如下：

相同數字的第一個關鍵測試案例

產品程式碼，相同數字的部分，使用 HashSet<T> 來判斷。

使用 HashSet<T> 判斷是否有相同數字

新增一個測試案例，nums = {5,6}, k = 1, return false;

這個測試案例用意為，當都不存在相同的數字時，該回傳 false。

測試程式碼如下：

數字皆不同時，該回傳 false 的代表測試案例

產品程式碼邏輯，如果每一個數字都不相同，回傳 false。

產品程式碼如下：

數字皆不同，回傳 false，消掉原本 NotImplementedException

還沒用到 k, 新增一個測試案例，nums = {5,6,5}, k = 1, return false;

這個測試案例用意，是假設 nums 中有重複的數字 5, 但其 index 差距大於 k，應回傳 false。目前會 failed, 原因是 HashSet<T> 只要加不進去就回傳 true。

測試程式碼如下：

相同數字距離超過 k 的測試案例

產品程式碼的實作，我這邊使用 slide window 的概念，也就是把 k 當作 window 的 size 基準。（嚴格來說是 k + 1，因為 k 是距離，window size 是 window 裡面的 int 個數），判斷 window 裡面是否存在著重複的數字，若存在則 return true; 否則 return false;

產品程式碼透過 Skip().Take() 取得 window 裡面的 numbers 判斷 window 中是否存在重複數字，如不存在，則往下一個 index 滑動。程式碼如下：

slide window 演算法初步實現

這一步跳比較大，

同時滿足了下面的測試案例：nums = {5,6,5}, k = 2, return true 的情況。

測試案例如下：

多個數字，相同數字符合距離 k 的限制

演算法的主要功能已經完成了，在我提供我的產品程式碼作法與 武可 討論之後，他提出了一個演算法優化的寫法。

目前產品程式碼的作法，是每次 window 要往右滑時，起一個新的 window 去拿框框內的元素，進而檢查是否存在重複數字。

而他的建議是，只保留一個 window 的 instance ，當 window 右滑時，如果有元素的位置已經不在 window size 框框內，就將其從 window 中移除。

重構後的產品程式碼如下：

fix window instance and remove element out of window before sliding

最後通過 leet code 的所有測試案例，並符合執行效能限制。

pass leet code all test cases

結論

1. 拿 leet code 來練 TDD 挺過癮的

2. leet code 通常都會針對演算法而有效能限制，而優化演算法效能的部分，很難從 TDD 來驅動優化的設計過程。

3. 但這並非代表 TDD 無用，因為在一開始使用 TDD 透過一個一個代表關鍵商業邏輯的測試案例，來一步步堆砌成滿足需求的產品程式碼，是很有幫助的。在這個過程中，會一步步釐清自己的想法與需求的複雜性。

到最後如果需要對效能或演算法進行優化，不論是判斷式或迴圈的搬移、合併、調整，甚至整個演算法重寫，透過版本控管的保護，你隨時可以還原到可運作的版本。透過先前完整的關鍵商業邏輯測試案例保護，你不必擔心優化或重寫演算法的過程中，漏了什麼特別的需求。

TDD 是種修煉，也是種習慣的養成。當你茫然毫無頭緒，想理頭緒時，TDD 讓你很容易下手。TDD 可以讓你先求有，再求好。

Commit History

我的 github commit history 可以看到 TDD 的過程。