第四部分: Go微服务 - 使用GoConvey进行测试和模拟html
如何对待微服务的测试? 当为这个特定领域创建测试策略时,是否须要考虑任何独特的挑战? 在第四部分,咱们将看看这些话题。数据库
- 单元上下文中测试微服务的主题。
- 书写GoConvey的BDD样式的单元测试。
- 介绍模拟技术。
既然本部分不会以任何方式改变核心服务, 这个时候无需基准测试。安全
微服务测试介绍
首先,咱们在脑海中应该记住测试金字塔的原则。架构

单元测试应该构成测试的大部分, 由于集成测试、e2e测试、系统测试和验收测试开发和维护成本愈来愈高。微服务
第二,微服务确定有一些独特的测试挑战,而其中一部分就如同在为实际测试服务实现肯定软件架构时使用的健全的原则(sound principles)。 也就是说,我认为微服务的细节超出了传统单元测试的的范围,这也正是本章内容要处理的问题。单元测试
无论怎样,我想强调几个点:测试
- 像日常同样进行单元测试: 你的业务逻辑、转换器、验证器等都没有什么神奇的,由于它们都是在微服务上下文中运行的。
- 集成组件,如和其余服务通讯、发送消息、访问数据库等操做的客户端应该考虑使用依赖注入和可模拟的形式设计。
- 许多微服务细节: 访问配置、和其余服务通讯、弹性测试等等若是不花费大量时间编写一个详单小的值模拟很难进行单元测试。将此类测试保存到类集成测试中,那样在测试代码中实际上将依赖的服务做为Docker容器。它将提供更大的价值,也可能更容易跑起来,运行起来。
源代码
待完善 spa
其余类型的测试
总结
关键术语
- 单元测试: Unit Testing. 是测试代码的自身行为。
- 集成测试: Integration Testing. 也叫组装测试或联合测试。 在单元测试的基础上,将全部模块按照设计要求(如根据结构图)组装成子系统或系统,进行集成测试。
- E2E测试: End to End Testing. 是一种模拟用户行为的测试。
- 系统测试: System Testing. 是对整个系统的测试,将硬件、软件、操做人员看做一个总体,检验它是否有不符合系统说明书的地方。这种测试能够发现系统分析和设计中的错误。如安全测试是测试安全措施是否完善,能不能保证系统不受非法侵入。再例如,压力测试是测试系统在正常数据量以及超负荷量(如多个用户同时存取) 等状况下是否还能正常地工做。
- 验收测试: Acceptance Testing. 验收测试是部署软件以前的最后一个测试操做。在软件产品完成了单元测试、集成测试和系统测试以后,产品发布以前所进行的软件测试活动。它是技术测试的最后一个阶段,也称为交付测试。验收测试的目的是确保软件准备就绪,而且可让最终用户将其用于执行软件的既定功能和任务。
- 测试驱动开发: TDD(Test Driven Development).
- 行为驱动开发: BDD(Behavior Driven Development).
参考连接