程序員必備的兩項(xiàng)基本技能
Spring在“清算”EJB的時(shí)候，提出的一大罪狀就是：強(qiáng)迫開發(fā)者繼承它的類，依賴容器，難于單元測試。
Spring的解決之道就是POJO，擺脫容器的控制，可以獨(dú)立創(chuàng)建和測試。即使是對SpringMVC這樣重度依賴容器的框架，Spring也提供了不需要Tomcat/Jetty運(yùn)行，就可以對代碼進(jìn)行單元測試的辦法： Mock。
不僅僅是Spring， 你可以看看自己正在使用的語言和框架，是不是都有單元測試的支持？
Java就不用說了， Python 語言有unittest， Python寫的Django框架也有django.test， Ruby 和Ruby on Rails 有TestUnit， MiniTest。 ReactJS 有 Enzyme， Vue.js 有vue-test-utils......
為什么這么多大牛都把單元測試加入到語言和框架中來呢？
答案很簡單，單元測試實(shí)在太重要了。
單元測試對于程序員來說，就是一個(gè)防護(hù)網(wǎng)， 能讓你有信心開發(fā)新的特性而不破壞現(xiàn)有的實(shí)現(xiàn)，與此同時(shí)，良好的單元測試，還能幫助別的程序員理解你的代碼。
尤其是對于動(dòng)態(tài)類型語言做的大型項(xiàng)目，沒有單元測試，修改代碼是一件“可怕”的事情。
一個(gè)代碼單元（可能是一個(gè)類，或者是一組類） ，如果被充分地測試過，這個(gè)代碼單元通常有這樣的特點(diǎn)： 和別的模塊耦合度低，是面向接口編程（只有這樣才能實(shí)施Mock，才能測試），這樣的代碼就是好代碼。
對于一個(gè)有追求的團(tuán)隊(duì)，對于一個(gè)想持續(xù)維護(hù)一個(gè)“正經(jīng)”應(yīng)用的團(tuán)隊(duì)，單元測試都是必備的。
同理，對于一個(gè)有追求的程序員，單元測試也是必備技能。
可能有些人會(huì)說，我們的項(xiàng)目很復(fù)雜，沒有寫單元測試，項(xiàng)目也運(yùn)行得很好啊！ 我想也許有這么幾種可能：
可能做的是一錘子買賣。
項(xiàng)目中已經(jīng)埋下了地雷，只是沒有發(fā)現(xiàn)。
在測試階段付出了巨大的代價(jià)，拼命加班，修改了無數(shù)的Bug。
當(dāng)然，有些單元測試是不容易寫的， 最難搞的就是遺留代碼， 你得想辦法解耦才行，這方面有人專門寫了一本書，強(qiáng)烈推薦。
沒有人一次就把代碼寫得既正確又優(yōu)雅，如果你是這樣的人，請告訴我，我得拜你為師。 當(dāng)然，我說的不是入門的Hello World，而是需要實(shí)現(xiàn)復(fù)雜的邏輯。
通往優(yōu)雅代碼的路徑就是不斷地重構(gòu)。
類名，方法名，變量名能不能準(zhǔn)確地表達(dá)意圖？ 讓人一看就知道是怎么回事？
方法是不是太長， 各種邏輯交織在一起， 能不能提取出新的方法？
類的職責(zé)是不是劃分得不好，導(dǎo)致有些類過分臃腫？
這個(gè)模塊如何進(jìn)行擴(kuò)展？ 對外暴露的接口用起來怎么樣？
......
強(qiáng)烈建議每個(gè)程序員寫完代碼以后，再審視一下，看看有沒有上面的問題。
如果有，那還愣著干什么， 趕緊改吧！ 可是改動(dòng)代碼破壞了功能怎么辦？ 要是有單元測試就不怕了。 兜了一圈，又回到了單元測試！
重構(gòu)要求在不破壞原有代碼的功能的情況下對代碼進(jìn)行改動(dòng)，讓它變得更好， 沒有單元測試是很難的。
對于重構(gòu)的具體技巧，我就不羅嗦了， Martin Fowler已經(jīng)總結(jié)了一本書：
總之，單元測試和重構(gòu)是程序員的兩項(xiàng)基本技能，他們和編程語言無關(guān)，如果你沒有掌握的話，很難說是一個(gè)合格的程序員。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請通過作者微信公眾號(hào)coderising獲取授權(quán)】
