【分析]程序員為什么不寫單元測試?(4) 單元測試工具
2、業務邏輯簡單，不值得編寫單元測試
程序員是聰明的，程序員也總是自認為是聰明的。認為一些業務邏輯比較簡單的類不必要編寫單元測試。我們必須承認，需求不斷變化，我們也必須要有勇氣去接受需求變化。編寫單元測試的另一個目的就是擁抱變化，而不是拒絕變化。編寫單元測試就是提高了我們對程序的信心。
在敏捷軟件開發中，代碼為項目組所有成員所有，項目組的任何一個人都可以去修改任何一個代碼文件。每當我要去修改一個別人編寫的代碼時，我總是多么的希望有程序的單元測試代碼，往往都讓我非常的失望。一般我都得花費很大的力氣去猜想作者的原始意圖。也許你會說：“你可以去看需求文檔啊!你不會去看注釋嗎?”。但實際情況是，當需求文檔完成了它的使命后，開發人員就把它扔到了一邊了，文檔總是過期的。沒有幾個項目組能夠使得需求，設計這些文檔與最新實現代碼保持一致。所以去看一個過期的文檔是沒有價值的。注釋也同樣，保持最新仍然是一個最大的問題，并且注釋能夠提供的信息是非常有限的。所以我最需要的就是看測試代碼了。測試代碼最能反映出方法最新的功能契約。由代碼的編寫者去寫的單元測試要比由其它人去編寫的單元測試要更完善、更準確。
很多問題恰恰就出在一些我們認為簡單的代碼中。除非是像一個JavaBean的getter和setter方法，因為這些方法可以通過IDE自動代碼生成，沒有必要為它編寫測試。
在項目開發中，我們需要經常通過重構來優化代碼及改進我們的設計,當我們對代碼進行重構之后，怎么能夠保證代碼仍然是正常的?那就是運行所有被修改的代碼的測試。如果測試通過，則說明我們的重構是正確。
我們不能回避代碼的維護問題。代碼維護包括修正bug和增加功能。維護工作可能會距離代碼編寫完成有很長一段時間。當需要修改一個bug而修改了代碼，或增加一個新的功能而修改了代碼時，又怎么能夠保證修改后的代碼仍然是正確的和沒有隱患的呢?
也許你會說，發布到應該服務器去測試就知道了。筆者曾經發生過因為維護而導致了更嚴重問題發生的情況。一個系統在生產環境正常運行很長時間了。某一天，業務人員要求修改某一個功能,筆者按業務的要求實現了要修改的功能，業務也測試了修改后的功能，然后發布到了生產環境。程序下發兩個星期后，報了一個非常嚴重的生產問題上來，以前能夠正常運行的功能突然有問題了，導致了大量的生產數據錯誤。這個問題是非常致命的，只能暫時停用系統。
最后我查明原因是，出錯的模塊與上次修改的代碼有關聯，上次修改時沒有同時去修改現在出錯的模塊。要是我能夠在修改代碼后，運行所有的測試類，測試就肯定會報告不通過。也就不會把隱藏有這么嚴重錯誤的程序下發到生產環境去。
我們看看沒有寫單元測試是怎么進行集成的。如果某些結果與我們所期望的不一致時，我們可能會在程序中加上許多print語句，然后通過控制臺來監視程序的運行過程。采用print語句并不能夠保證我們的程序的正確性。最好的情況是，它只能保證一條正確的路徑，不能保證其它的分支。另外當太多的print語句的信息在控制臺上，也會讓我們看不到想看到的信息——控制臺的信息是有限的。在開發測試時，把調試信息打印在控制臺還可以接受，但是在生產環境，如果還有調試信息出現在控制臺，那是絕對不可以接受的。我們經常會忘記把調試的print語句及時的刪除掉，從而影響程序的性能。最關鍵的是，print語句不能保證程序的正確性，也不能為你節省開發的時間。只會給你帶來負面的影響。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
