這是碼天狗週刊在fb上分享的一篇文章，試著寫寫讀書心得
看完開頭第一段，我的看法是他在談End to End tests是比較花費時間的測試方法，所以不應該著墨過多。
在正文開始，作者先描述google的 ten things we know to be true。
第一項原則是focus on the user and all else will follow，也就是以使用者為優先。
接著描述理論上的e2e測試，由於focus on user，因此照理說，從使用者角度出發的e2e測試應該很棒。
但是在實際上的狀況，由於e2e測試關係到複雜的操作情境，所有有可能其中一個步驟的程式碼出現問題，造成後面所有步驟，甚至所有e2e測試因此失敗。
同時由於e2e測試執行時間長，所以效率會比較差
看到這邊的感想，這是合理的，因為e2e測試本來就比單元測試更複雜，畢竟e2e測試的目的就是在透過情境來模擬使用者操作。
What went wrong，在這一段作者也給了結論，由於e2e測試複雜，也因此也更為脆弱。
在我認知中也的確是這樣的，我自己在使用specflow作情境的時候，也確實遇到維護上的困難。往往因為一個需求異動，很多情境都要打掉重練。
那應該怎麼辦?
以我目前的認知，是單元測試為主、e2e測試為輔。
但是目前要完全切換成單元測試優先的模式，會有習慣性的困難。
我目前的看法，是認為可以先以一半一半為目標
接下來文章談到測試的真正價值
從focus on user的角度出發，那要思考當測試失敗的時候，對使用者有甚麼幫助?
失敗的測試不會直接對使用者有幫助。
找出bug並修復，對使用者有幫助。
整個價值鏈是這樣的：
測試失敗->找到bug->修復bug
整段流程只有在最後一步，修復bug，對使用者才有直接幫助。其他都是間接價值。
因此在評估測試方法，不能單獨看這個方法如何找到bug，而是要把如何幫助開發者修復這個bug也一並考量進去
建立正確的feedback loop
三個重點
Fast
Reliable
Isolates failures
看到這邊的感想，不就是在講單元測試嗎?
的確結論就是在講要建立單元測試，並且依照測試金字塔原則。
單元測試為基礎、再來是整合測試、最後才是e2e測試。
建議的比例：70/20/10
需要避免的反patterns：
倒金字塔形狀：很少或幾乎沒有單元測試，反而是大量的e2e測試
沙漏形狀：很多單元測試、很多e2e測試，但是缺少整合測試，這代表我們用e2e測試來做很多原本整合測試就該做的事情
