從另一個角度告訴你單元測試的意義(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/