喔?

首先，單元測試，讓我補足了以前學測試相關的知識。至少從現在開始，我有了辦法可以為任何舊的code，開始進行加測試的動作。在這之前，我只能拚拚看，或者用腦袋模擬情況。因為很多時候，舊的code都是在，想要加測試，就需要重構才能加測試；但要重構，就得要先用測試來保證程式仍然可以用，結果就變成無解的迴圈了。

其次是講DI的部分，因為之前有看過91老師部落格上面的30天TDD的重構九式，所以這部份還算清楚。

然後還有講了一些，test的壞味道。
其中一個我印象滿深刻的是，測試名稱不要用test_SUT_input_output這種類型的......一開始聽到的時候，讓我整個人震驚了，單元測試的藝術不是這樣寫的嗎? 在接著聽老師解說後，才知道因為那樣的測試名稱，沒辦法表達這個測試的情境，單元測試的藝術上面寫的是邀我們寫情境，而不是寫測試細節。這讓我回想到clean code說的，上層都是下層的抽象(有個大概是類似這種意思的地方)，我之前從未對策是以這種角度來看，看來我一直以為我有把測試當程式來看待，但並沒有www

還有另一點顛倒了我的認知的是，寫測試最好不要去看production code。
原本想說，unittest應該算是白箱測試吧，所以應該要看懂production code，這樣才能夠寫出正確的驗證。結果反倒是比較類似於黑箱，至少一開始的思考是比較接近於黑箱的角度，這樣才能夠從比較抽象的角度、情境，下去寫測試，才能夠去逼出實際上的需求，但又不會讓測試過於over fitting。

----------------------------------------
接著講今天的極速開發。

其實一開始我是以了解更多vim還有ide的功能的能做到哪些東西(例如JetBrains系列的一些功能的shortcuts) 的心態來上課的，讓自己能夠知道有哪些事情可以做得到，這樣以後遇到的，就會想起這個別人可以做到，進而去找怎麼做。

雖然之前有看到以前的學員的心得，講說這堂課不只是教VIM而已，而是教你怎麼利用vim和IDE來做到各種事，加速coding。但我還只是以為，大概就是利用vim的各種操作，然後再用IDE的各種功能。自己一個個功能按出來

結果沒想到，居然真的是整合起來，而且還可以各種組合，並且弄成新的shortcut......

當我看到IDE的VIM plugin居然可以呼叫IDE的功能時，我整個嚇到了，這簡直是太離譜了，居然可以這樣玩，這當初到底是怎麼發現的阿，真不愧是91。

--------------------------------------------
結束