文章目录
测试驱动编程(2)进阶单元测试(上)
单元测试
要打造出出类拔萃的作品,你必须专注于最小的细节
单元测试正确打开方式
- 单元测试应该是测试流程中占比最重的部分
- 单元测试通常来说是指方法,但是有些情况下,整个类乃至整个应用程序都可视为单元
- 单元测试是为了缩小其它(功能,集成)测试的范围,如果一个组织主要依赖于手动测试,这本身就是有问题的
- 单元测试编写更容易,也能让代码的问题尽早暴露
- 单元测试为代码重构提供了有力的支持
各类测试比较
下图测试金字塔展示的是UI测试、集成测试、单元测试之间的比重,单元测试要比其它测试多得多
拿最常见的用户注册测试场景举例,最常看到的测试用例就是要考虑用户名为空、密码为空、用户名格式、密码格式、用户名是否存在、密码安全等级等等。
仅为测试这一项功能,就可能需要数十个测试,再加上边界值等情况可能导致上百个测试用例,如果是人工的UI测试,那么代价将是非常大的。
如果使用单元测试来做这些会简单和方便的多,人工只需要填写一个集成测试,检查是否调用了正确的后端方法即可,而无需关注细节。当注册逻辑发生改变了也没关系,因为新单元测试会自动进行测试。
TDD中的单元测试
TDD中的单元测试和传统的单元测试有什么不同呢?答案是:时机
看过我之前写的一篇文章,测试驱动编程快速入门的应该都知道了一个名字:红绿重构
传统先写业务再写单元测试,主要是为了验证业务代码写的对不对,而TDD中的单元测试主要目标是作为驱动开发和设计的动力,定义了我们应该做什么以及做到什么程度,验证只是副产品。
完成的工作量和具体的测试(单元、功能、集成)有关,TDD中的单元测试制订接下来完成尽可能小的任务,要求我们遵循一些设计原则(KISS、SOLID),确保代码的可测试性和解耦性。
TDD迫使我们详细地考虑需求和设计,编写整洁而可行的代码,以及创建可执行的需求并频繁重构。