做為一個程式設計師, 深深知道計算機自動化的速度是比人手動的速度快的, 所以”快速”完成專案的一個重要武器就是: 能自動化就不要手動.   BDD/TDD有很多優勢, 其中之一就是自動化, 我們這節文章先講自動化, 在後面的文章裡面會講到BDD/TDD的其他優勢.   在ABP .NET Core + SPA版本和52ABP裡面, 可以在以下層面做自動化測試:

1. 前端Angular專案的e2e自動化測試
2. 前端Angular專案的unit test
3. 後端.NET Core專案的unit test
4. 後端.NET Core專案的整合自動化測試

  首先, 所有層面都寫自動化測試程式碼, 是不符合 康威定律第二定律的. 嗯,  康威定律是微服務的理論基石, 很顯然我們不能違背它. 如果你之前真正運用過BDD/TDD, 那麼我推薦只寫前端Angular專案的e2e自動化測試就好了. 具體怎麼寫在這系列課程的序裡面有詳細描述< 如何用ABP框架快速完成專案 - 自動化測試 - 前端angular e2e protractor>   然後根據 康威定律第二定律, 我們很顯然不能像十年前2008年時候那樣追求程式碼覆蓋率80%以上. 我個人認為能把人工手動要跑的Postivie所有測試用例和主要的negative測試用例全部轉為自動化, 這已經足夠了.   有同學說, angular官網是不推薦寫e2e測試, 而是推薦寫unit test的. 是的, 沒錯. 但是這是針對團隊的專案和有BDD/TDD基礎的同學來說的, 對於沒有BDD/TDD基礎而又一個人做一個專案的同學, 我認為還是寫e2e測試比較好, 因為直觀啊! e2e測試會彈出chrome瀏覽器UI, 這樣如果測試跑不通過, 很直接的就知道原因在哪裡了, 修復的時間和精力會大大減少.   不過, e2e測試會對電腦硬碟和記憶體要求比較高, 起碼要是SSD硬碟和16G記憶體才會跑得流暢, 不然會經常性報錯.    做為一個程式設計師, 深深知道計算機自動化的速度是比人手動的速度快的, 所以”快速”完成專案的一個重要武器就是: 能自動化就不要手動.   BDD/TDD有很多優勢, 其中之一就是自動化, 我們這節文章先講自動化, 在後面的文章裡面會講到BDD/TDD的其他優勢.   在ABP .NET Core + SPA版本和52ABP裡面, 可以在以下層面做自動化測試:

1. 前端Angular專案的e2e自動化測試
2. 前端Angular專案的unit test
3. 後端.NET Core專案的unit test
4. 後端.NET Core專案的整合自動化測試

  首先, 所有層面都寫自動化測試程式碼, 是不符合 康威定律第二定律的. 嗯,  康威定律是微服務的理論基石, 很顯然我們不能違背它. 如果你之前真正運用過BDD/TDD, 那麼我推薦只寫前端Angular專案的e2e自動化測試就好了. 具體怎麼寫在這系列課程的序裡面有詳細描述< 如何用ABP框架快速完成專案 - 自動化測試 - 前端angular e2e protractor>   然後根據 康威定律第二定律, 我們很顯然不能像十年前2008年時候那樣追求程式碼覆蓋率80%以上. 我個人認為能把人工手動要跑的Postivie所有測試用例和主要的negative測試用例全部轉為自動化, 這已經足夠了.   有同學說, angular官網是不推薦寫e2e測試, 而是推薦寫unit test的. 是的, 沒錯. 但是這是針對團隊的專案和有BDD/TDD基礎的同學來說的, 對於沒有BDD/TDD基礎而又一個人做一個專案的同學, 我認為還是寫e2e測試比較好, 因為直觀啊! e2e測試會彈出chrome瀏覽器UI, 這樣如果測試跑不通過, 很直接的就知道原因在哪裡了, 修復的時間和精力會大大減少.   不過, e2e測試會對電腦硬碟和記憶體要求比較高, 起碼要是SSD硬碟和16G記憶體才會跑得流暢, 不然會經常性報錯.   有同學問, 對於ui自動化測試這方面，是不是ui變化了，無論使用何種測試框架，都避免不了重新編寫測試用例的程式碼？ 這是必然的, 在這點上, 不會會計的程式設計師不是個好的專案經理，是要根據自身實際計算成本收益並進行取捨。 為什麼會扯到專案經理這個角色呢? 首先一個UI短期經常變化的專案, 專案經理是有責任的, 因為即使不寫自動化測試程式碼, 純手動測試, 你也要花時間去修改UI的程式碼啊. 這個鍋無論如何都輪不到自動化測試去背, 應該有專案經理或產品經理去背.   自動化的另一個利器就是DevOps了, 在這方面, 徐磊有十分豐富的 課程文件, 我想我是不可能做得比他更好的啦, 所以推薦大家閱讀.