對，我就是用了工程師從0開始數的老梗。
最近要來做測試，想把以前從書、從 blog 、從 youtube學到的內容整理一下，談一下為什麼要寫測試，甚至記一下怎麼用工具做測試。
測試是為了重構，重構是為了開發
背景
需求不可預測，所以我們要追求軟體彈性，讓軟體可以適應一直變化的需求。
什麼是重構
重構在外在行為不變的前提下，讓程式碼更加可讀，增加程式碼的可修改性。讓程式碼更簡潔，進而加速開發效率。
重構依賴測試
重構的前提就是在外在的行為不改變，而要確保外在行為不改變就是單元測試可以為我們辦到的事情。
重構完就結束了嗎？並沒有
下次需求來了，舊的架構還是會不足以應付新的需求。對新的需求來說，你還是不夠彈性，不夠好修改。
那怎麼辦？
那就不斷的重構，新的需求來一次，我就重構一次，不滿足新需求的部分就改掉。來一次我就改一次，來一百次我就改一百次。
重構是為了開發
越複雜的程式開發得慢，但往往專案的進展會讓程式變複雜。
假設我們程式的複雜度隨著專案進展線性增加，最後我們的總開發時間可能會是指數的增加。
因此我們要透過一次次的重構降低複雜度，阻止架構陳舊、複雜到改不動，阻止開發時間爆炸。
每一次開發的責任除了滿足新的需求，還有阻止程式碼變得更為複雜，提升架構的彈性還有適應新需求的能力。
測試是為了重構
以測試支援重構
舊的程式碼會一直被重構，在這過程中，我們必須要一直檢查被重構的單元，確保外部的行為仍保持一致。
以不斷測試支援不斷重構
每個重構的地方可能都非常的小，手動單元測試並不會太麻煩。我們可以選擇每次都手動測試每個單元，但這不是工程師的作風，會重複做的事就該交給程式碼來做。
如果照著前面的想法，我們要不斷的重構不斷的測試，如此一來撰寫單元測試就是一個很自然而然的事情。我們要透過不斷的單元測試來支持我們不斷的重構。
測試也是為了開發
甚至不用重構，一般的開發過程中，在舊的程式碼增加新的功能，就是一個超級容易弄壞東西的狀況。每次在這種時候總得小心翼翼，先去理解舊的程式碼到底為什麼這麼寫，在什麼情況用到他。
這樣寫程式好累= =
單元測試增加了開發時的信心，增加了開發效率。沒有考慮到的舊需求，以前寫的測試都幫你考慮了。甚至在測試沒通過時，直接指出了沒有考慮到底需求是什麼，省去尋找舊需求的時間。
總結
在重構裡，童子軍原則要求路過就讓程式碼變好。Clean code 第十四章就是持續地精煉的程式碼。甚至我自己的指導教授也會去看舊的程式碼，要求把程式碼越改越好。
所有的道路都匯集到同一個座標上，要求不斷的讓程式碼越來越好。測試就是讓程式碼越來越好的工具，重構就是讓程式碼越來越好的過程。
至於如何用 jest 還有 react testing library 測試 react 的 components ，這個我們有機會再寫一篇來說。
