記錄某天下午練習用TDD解bug的過程
整個解bug的過程用了一個下午。整個過程中，有約50%時間是在設法用測試案例重現bug，另外有約20%的時間是在排除因為解bug而引入的新bug，只有約30%的時間是真正用在解bug上。
在這個下午，表面上對目前系統的價值只有一個：
- 我們修復了存檔時的bug。
如果不採用測試案例，以自己對系統的了解，修復的時間應該可以加快。
但是也會因為沒有完整的測試案例，造成我無法發現後面因為修bug而產生的新bug(之後的四個紅燈案例)。
因此，我認為這個下午真正的價值是：
- 修復目前的bug
- 確保不會引入新的bug
另外需要檢討的地方。因為整個過程中還是偏重在用specflow做整合測試，真正應該做為基礎的單元測試反而被我刻意忽略掉。又因為解bug而調整程式邏輯，進而造成與原先寫好的測試情境預期不一致。
而這個不一致只是因為存檔的取序號邏輯被改變了。
學到了兩件事：
- 要以單元測試為基礎。
- 用情境做整合測試的時候，不用太計較序號、時間這類容易變動的屬性。
以下簡述整個解bug的過程過程：
- 使用者發現系統bug，在這次的case是儲存紀錄時會出現Key重複的例外
- 透過測試案例重現系統bug
- 接著設法讓測試案例通過，代表bug被修復
- 重新執行所有測試案例，目的是為了確認沒有弄壞其他東西。但執行結果告訴我們有四個測試因為這次的修改而失敗。
- 最後通過所有測試案例，確認系統修復，此時才更新系統
