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