做為一個程序員, 深深知道計算機自動化的速度是比人手動的速度快的, 所以”快速”完成項目的一個重要武器就是: 能自動化就不要手動.
BDD/TDD有很多優勢, 其中之一就是自動化, 我們這節文章先講自動化, 在后面的文章里面會講到BDD/TDD的其他優勢.
在ABP .NET Core + SPA版本和52ABP里面, 可以在以下層面做自動化測試:
- 前端Angular項目的e2e自動化測試
- 前端Angular項目的unit test
- 后端.NET Core項目的unit test
- 后端.NET Core項目的集成自動化測試
如果你之前沒有接觸和運用過BDD/TDD, 那么我推薦只寫前端Angular項目的e2e自動化測試就好了. 具體怎么寫在這系列課程的序里面有詳細描述<
如何用ABP框架快速完成項目 - 自動化測試 - 前端angular e2e protractor>
然后根據
康威定律第二定律, 我們很顯然不能像十年前2008年時候那樣追求代碼覆蓋率80%以上.
我個人認為能把人工手動要跑的Postivie所有測試用例和主要的negative測試用例全部轉為自動化, 這已經足夠了.
然而有同學反映, 我這個說法太抽象了, 很難執行. 我想了想, 的確是, 沒有基礎的同學可能並不能掌握哪些是Positivie Test和Negative test.
這樣吧, 你寫完成程序后, 手動測試一遍, 然后把你剛才做的手動測試自動化就好了. 這么一說, 應該是比較直觀和可執行的吧.
有同學說, angular官網是不推薦寫e2e測試, 而是推薦寫unit test的. 是的, 沒錯. 但是這是針對團隊的項目和有BDD/TDD基礎的同學來說的, 對於沒有BDD/TDD基礎而又一個人做一個項目的同學, 我認為還是寫e2e測試比較好, 因為直觀啊! e2e測試會彈出chrome瀏覽器UI, 這樣如果測試跑不通過, 很直接的就知道原因在哪里了, 修復的時間和精力會大大減少.
不過, e2e測試會對電腦硬盤和內存要求比較高, 起碼要是SSD硬盤和16G內存才會跑得流暢, 不然會經常性報錯.
做為一個程序員, 深深知道計算機自動化的速度是比人手動的速度快的, 所以”快速”完成項目的一個重要武器就是: 能自動化就不要手動.
BDD/TDD有很多優勢, 其中之一就是自動化, 我們這節文章先講自動化, 在后面的文章里面會講到BDD/TDD的其他優勢.
在ABP .NET Core + SPA版本和52ABP里面, 可以在以下層面做自動化測試:
- 前端Angular項目的e2e自動化測試
- 前端Angular項目的unit test
- 后端.NET Core項目的unit test
- 后端.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了, 在這方面, 徐磊有十分豐富的
課程文檔, 我想我是不可能做得比他更好的啦, 所以推薦大家閱讀.