Util应用框架快速入门（四）- 集成测试 快速入门

集成测试 快速入门

Util应用框架集成测试快速入门

本节演示Util应用框架开发的项目中如何编写集成测试.

准备

完成 Web Api 快速入门,本节将在之前生成的示例项目上讲解集成测试的开发.

测试概述

自动化测试对于Util应用框架的开发非常重要,它能保证基础功能的稳定性.

对于使用 Util 开发的业务项目,自动化测试不是必须的,但掌握它可能很有用.

如果你使用 Util 开发 Web API,可能会使用 Swagger 进行测试.

将 Swagger 提供给前端人员是合适的,但后端人员使用它却不够省力.

原因很简单,使用 Swagger 测试 API,需要设置一堆参数,这些参数无法保存,每次运行都需要设置.

使用 .Net 自动化测试会更加方便,并且现在开发集成测试的成本很低.

专业测试的分类非常细,下面简要讨论自动化功能测试.

测试分类

这里粗略的对自动化功能测试概括为两类:

• 单元测试

  • 隔绝外部依赖,仅测试自身的某些功能.
  • 如果需要访问外部依赖,通过定义抽象接口的方式使用,不能直接引用.
  • 在 Util 分层架构中,一般对领域层实体,值对象,领域服务实施单元测试.

• 集成测试

  • 直接访问外部依赖,对关联的所有类型进行测试.
  • 在 Util 分层架构中,一般对基础设施层仓储,应用层应用服务和API接口进行集成测试.

测试的好处

修改任何一行业务代码,都有可能影响之前的逻辑.

自动化测试基于对业务功能的预期反应,如果预期未发生变化,但你的代码逻辑出现变化,就能帮你拦截这个错误.

测试的弊端

• 除了开发自动化测试本身的成本以外,更大的成本在于维护.

• 每当需求变更,需要删除已经过时的测试,开发新的测试,修改之前的测试以符合当前预期.

测试编写条件

自动化测试的语法非常简单,但并不是掌握了测试语法就能编写出有效的测试.

编写单元测试需要开发人员有一定抽象思维,能够抽象和隔离依赖,还需要了解一些单元测试技巧.

不要在公司全面推行单元测试,容易变成形式主义,仅让团队核心骨干对高价值业务模块编写单元测试.

集成测试则要简单得多,只要懂得测试语法就可以编写.

集成测试由于直接访问外部依赖,运行缓慢,而且任何环节变更都可能导致测试失败,所以不宜大量编写.

你是否需要它?

• 如果你仅负责编写 Web API ,手头没有现成的UI进行测试,编写集成测试比使用 Swagger 省力.

• 如果你没有打算持续维护这些测试,不要编写它们,那只会浪费时间.

• 如果你的团队精力有限,无法维护大量的测试,可以仅