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

。不少团队怀揣微服务架构的梦想，却在老一套组织架构的驱使下渐行渐远。最后迫不得已，将原来一个大Team按照功能模块拆成几个小Team，将代码库粗暴地拆分成多个，每个开发人员同时往所有的代码库中提交代码。

微服务架构的优势会驱使团队在一开始就高架微服务，无视业务需求复杂度，走一遍Event Storming，来一场DDD活动，确定几个服务便开始搞下去。而微服务架构提倡的是演进式架构，某些团队却因为各种原因一直停留在起初确定的那几个服务下开发下去，拆分的不合理性和演进性没有得到体现。这足以扼杀微服务架构能够应对复杂业务需求 的特性。

微服务架构本身并没有错。归根结底是业务的复杂性很难被驾驭。我们说DDD可以帮助做微服务设计，于是我们都来学习Eric Evans 的DDD，可它却不能有效解决以下几个问题：

• 如何进行领域建模？
• 如何划分限界上下文？
• 如何在实现层面定义对象？

所以，我们学习了DDD还是不会DDD。但有一点毋庸置疑，我们每个人（DEV）都会编写单元测试。我们在试图驾驭微服务架构的路上摒弃了陈旧的集成测试、掌握了新的契约测试，而任何时候我们都应该始终抓住根本：编写有效的单元测试来为我们的系统保驾护航。

---

三个维度看单元测试

我们不会说单元测试是灵丹妙药，对于100%覆盖率我们也应该持有保留态度。但在一个微服务架构基础设施还不完善、开发人员能力参差不齐、DDD能力不足以应对复杂业务的情况下，单元测试是性价比最高的实践。

能力建设

一个具备开发经验的开发人员，基本上都会编写单元测试。即便不会，可以通过培训来快速达成。从学习曲线上看，单元测试很容易上手（方法难以被测试另当别论），拥抱Java大腿的JUnit就是一个很好的例子。所以在一个团队中，我们可以过培训、Pair 快速让开发人员具备编写单元测试能力。

测试即文档，对于新上项目的开发人员，可以通过阅读单元测试来了解业务需求，并且不会对一系列具备复杂数据安装的Service测试产生恐惧感。

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