模板
教程
环境
性能
功能
管理
从另一个角度告诉你单元测试的意义(2)
发表于：2018-02-09来源：袁慎建作者：袁慎建点击数：
标签：
，尤其是契约测试伴随着业界对集成测试（UI测试）的痛斥声而崛起。 消费者驱动契约测试 的演讲比比皆是，我也没有例外，在某Account的技术大会上做了
，尤其是契约测试伴随着业界对集成测试（UI测试）的痛斥声而崛起。消费者驱动契约测试的演讲比比皆是，我也没有例外，在某Account的技术大会上做了一次 微服务架构下的测试应对策略 的分享。在分享中，我赶时髦提倡用契约测试取代集成测试，但是细节中没有忽略的一个核心点：单元测试。这也是本文我要分享的重点。
基本最无敌
单元测试是根，是基本，基本最无敌
单元测试存在于测试金字塔的底端，撑起了整个金字塔，编写它是开发人员的职责。微服务架构让服务更加独立小巧，这意味着我们不用为小巧的代码库编写单元测试了吗？微服务架构提倡服务与服务之间通过契约测试来集成，这意味着我们只用编写契约测试就足够了吗？
假设我们以正确的姿势在践行微服务的相关技术实践。
CI上会伴随每次提交都触发单元测试、Service测试（API测试）、契约测试，所有测试通过后开始独立部署，如果我们的契约测试写的足够好，便可以自信地独立部署。如果Service测试覆盖的足够全，便可以自信地说代码缺陷率很低。此时我们可能认为单元测试业务价值低，不必过多关注。
回到现实，实际情况可能是这样子的。
CI上有契约测试的Stage，但也是草率编写，甚至契约测试因为没人维护而被默认忽略。Service测试写了大量的Case，导致测试运行时间被拖长，Build效率大大降低。由于大量的Servcie测试的存在导致单元测试被过度轻视，再加上无效的测试充斥着代码库。这几点不但扼杀了服务独立部署 的特性，而且增加了开发部署的工作量。
再者，根据康威定律： 原文转自：http://sjyuan.cc/significance-of-unit-test-from-other-sight/系统架构取决于组织架构，它俩息息相关
