做为一个程序员, 深深知道计算机自动化的速度是比人手动的速度快的, 所以”快速”完成项目的一个重要武器就是: 能自动化就不要手动.
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内存才会跑得流畅, 不然会经常性报错.
做为一个程序员, 深深知道计算机自动化的速度是比人手动的速度快的, 所以”快速”完成项目的一个重要武器就是: 能自动化就不要手动.
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了, 在这方面, 徐磊有十分丰富的
课程文档, 我想我是不可能做得比他更好的啦, 所以推荐大家阅读.