為什么寫這篇文章

現在的工作需求，讓我有必要總結和整理一下。
凡事都有適用的場景。首先這里我需要提示一下，這里的信息，可能并不普適。
但是可以肯定一點的是，有些人，不論做事還是寫書，上下文還沒有交待清楚，就對你說單元測試如何重要，這種是極為無恥的。
是的，我是說無恥。因為說風涼話的人，他們不需要像那些奮戰在一線的程序員那樣，需要面對結果質量與進度和成本，以及維護性之間的考量，他們只需要在意自己說的話是不是看來永遠正確即可。
這么說吧，一個想要他說的話永遠正確，只需要故意將上下文刪除即可，這也就是人們常說的站著說話不腰疼，或者永恒正確的廢話，或者何不食肉糜之類的正確但無用的話。這些話往往常出現在書籍上。

但是，現實中，我們每天都需要面臨痛苦的選擇：是讓自己良心好受一些，寫出質量過得去的程序，還是讓老板看到，我又出活了這樣的表面文章。

所以，我們必須要考慮如何測試，以及如何避免重復相同的錯誤這樣的問題。

然而，測試從來不是一件簡單的事，事實上，我的碩士論文寫的就是如何在被測對象升級之后，自動測試的腳本，能夠95%以上自動升級的故事。這個我們不多說了。但大家都知道這是一個困難的事情。所以我的論文開篇講的是自動測試的消亡史。

講到測試，我們就不得不考慮測試的方法。
所有的書上，都強調Unit test是必不可少，多么重要。

這點了解我的人都知道，我是嗤之以鼻的。

正確的事，就好比亞當.斯密的《國富論》，認為自由競爭是是經濟的基石；而事實是，人們總會有想盡辦法使自由競爭失效。
同樣，這些看似正確的廢話，只能帶來災難。軟件行業的災難性失敗還少嗎?這些大公司沒有做單元測試嗎？
以微軟為例，2003年，當時我還在某為，聽說微軟過了CMM2級，我說了一句：微軟從此再也不能開發出有完整度的軟件。一語成讖。

鋪墊這么多，就是想對一些人說：凡事需要考慮上下文，不要被所有的書里都認可的話所蒙蔽：所有的寫書的人，大多沒有在一線工作過。

單元測試VS模擬（或仿真）程序

后面我們來比較一下這二者

單元測試的適用范圍

1。 相對簡單的程序或產品。
2。 與設備無關的程序或產品。
3。 需求變動相對慢的程序或產品。
4。 設計良好，接口清晰，與人機界面交互不多的多線程的每個模塊或層之間。
上述為一般的單元測試能取得良好效果的上下文。

單元測試的問題

對代碼有依賴。

這顯然是最嚴重的問題。
有人說，為什么我要極客編程的原因正是如此，因為以前測試與研發是相對的，因為體制要求如此，但測試發現，研發的人可以隨意改代碼，所以白盒測試就消亡了。
所以，管理者就想到讓程序員吃自己的狗食這樣的損招：自己寫自己的單元測試——反正嘴一動就可以了，這多簡單。他們不考慮這么做帶來的后果是什么。

這是一個悲哀的時代的原因是真正的程序員，已失去是了話語權。
那么有人說，是你自己的狗食，做得不好吃是你自己的問題。
然而事實真的是這樣嗎？
需求變動，產品經理認了客戶當干爹，他敢對干爹說不嗎？
還是苦一苦程序員吧。
設計錯誤，所有的PMP（我不是說PMP認證，我是說拍馬屁那個PMP）的組長，敢對總工說不嗎？
還是苦一苦程序員吧。
接口常變動，程序員同樣沒有權力找橫跨多個部門的技術官僚體系去說理。
還是苦一苦程序員吧。

所以，這狗食難吃，也許只有不到1%的問題，在程序員。
所以，程序員現在不僅要捏著鼻子做難吃的狗食，還要自己吃了。

當然我們需要肯定單元測試的價值

如果你有良好設計的復雜的程序，所有的模塊相對獨立，接口相對穩定，
并且這個程序是多線程程序，那么單元測試是能發揮出極大的價值的。
如果再加上我寫的論文里描述的，當被測對象發生改變時，自動測試腳本也能自動升級，顯然對程序員是有利的。
當然，這是永恒正確的廢話。
因為分工是你程序員澆水，官僚體系吃桃子。
嘔，我忘了說，這種分工很公平：一棵樹，一人一半，你要下面，我要上面。你一直澆水，我一直吃桃子，對了，老吃桃子也很累人的，你們澆水人不會懂我們的痛苦的。一人一半，很公平，放稱上稱稱，一定一樣重的。。。
或者說，除非這項目是你一個人在寫。
多數情況，單元測試害處多于利益。
原因很簡單，導致這種情況的官僚體系，是無人問責的（單向向上體系）。責權不對等。當然，他們吃桃子也很累，我也很有同理心的。

所以總結：
一個人的項目，而且項目很復雜，設計可控，接口清晰，需求清楚，而且你要對被測的對象非常了解，才可以。

模擬（或仿真）程序

當然一般我們是指模擬程序。除非有條件（作設備仿真）。
人們有個誤解，認為互聯網程序代表程序員，這顯然是錯到離譜，離了大譜。
廣大的程序員，是需要與設備或硬件打交道的。
所以，模擬或仿真程序，是至關重要的。
原因是絕大多數公司，無法提供足夠的硬件給程序員。

程序員的困難在于，有困難無處去說，比如說，我需要行拿到設備，才能逐漸的了解它的習性；
但領導卻堅持認為，你是懂的，你非常懂。
等你剛懂，這個項目完事了，新的設備又到了。
所以，程序開發是個動態過程，這些話，領導是無法理解的，因為中國的情況，目前的領導都是硬件出身，麻麻不懂。而且也不講道理。我這么說是有依據的。

在這樣的情況下，寫單元測試，是相當離譜的。

但是，寫模擬程序卻是非常必要的。

這是從技術開發和技術管理兩個視角來看的。

因為模擬程序的仿照對象僅僅是我們的target，而unit的服務對象卻是我們的程序。
這個你稍微理解一下就懂了。一個是對哈雷彗星，另一個是對哈雷將軍。

也就是說，我們自己寫程序，是最不可信的，因為你在信息的最后一道工序，沒人在乎你。
但設備不同。
所以，不論你如何改代碼，都不會影響simulator。
這是最關鍵的要點。與unit test不同。
我常說，第一點占75%以上。
但是后面的不重要的理由我們也要說說。

資產保值性

資產保值這件事，也是有水分的。因為你得是“資產”，才有必要保值。
一堆垃圾代碼，它就不是資產。
單元測試的代碼，往往如此。因為它要測的對象如果是個垃圾，它就一定是垃圾。

可是，simulator卻不是這樣的。
因為它mirror的對象是真實的設備。
隨著公司工程的一年一年的積累，這個simulator會變成emulator的一部分，最后會變成產品的一部分，最后，會比產品更好。

以ABB的機器人為例，了解過的人都知道它的simulator有多強。FPGA的程序，DSP的程序，直能能跑。機器人也是三維CAD動畫模擬出來的。
用戶不需要買robot就能完全與買了一樣給機器人編程。

這個算是15%？

管理角度

利用分工，也就是說，大公司，可以專門派專人寫simulator,這點其實非常有價值的。注意是專崗。
如果有公司這么做，說明這老板有水平。
盡管中國大多是垃圾公司，管理極為垃圾。
但如果你的老板有這水平，恭喜你。盡量多干幾年。
啊對了，你不可能設立專崗寫unit test。前面這我解釋得好多了。

后記

可千萬不要以為，單元測試不重要。
其實我也寫的。
因為我能做到可控。
因為是我一個人在干。我對我的能力也相當自信。所以我用。
但我盡最大可能，會集中精力寫模擬程序，因為太必要了。