从另一个角度告诉你单元测试的意义

当下微服务如火如荼，各个团队在争先恐后推出微服务，不论在概念上还是在实践上，如果自己没有跟微服务挂上钩，便会被贴上落伍的标签。我们在推微服务的时候，我们说微服务架构具备如下优势：

• 架构灵活，能够应对复杂的业务需求。
• 独立部署，大大提高CI/CD的效率。
• 服务自治，支持技术栈多元化。
• ……

这些特征恰恰是单点应用无法具备的，因此微服务架构在广大的呼声下逐渐承接了单点应用的替代工作。随着容器技术的成熟，使用Docker重建一个应用的成本趋近于零。而K8S/Rancher在生产上的广泛应用，很大程度解决了容器管理的难题。调用链分析工具（ZipKin）、ELK+Kibana再配合系统监控工具（Prometheus），就连微服务架构带来的部署运维的复杂性也得到了大大的改善。更加乐观的是，众多云平台（AWS, GCP, Azure等）正在试图打造解决部署运维难题的一体化Paas服务，让应用开发商更加专注于业务上。

如果将软件生命周期大致划分成两部分：

我们认为左边部分正在享受着微服务架构的益处，而右边部分在遭受着微服务架构复杂性的折磨。

微服务架构带来的复杂性（右边部分）已经很大程度上得到了解决，常见的解决方案是在开发团队中植入DEVOPS。比如在ThoughtWorks中的某些团队，DEVOPS成为Team不可或缺的成分。

我们把注意力放在左边部分。开发人员关注更多的是开发，每个服务由一个小的Team负责开发，Team正在极力往服务自治的方向靠拢。测试人员可能更加关注测试

原文转自：http://sjyuan.cc/significance-of-unit-test-from-other-sight/