世界著名開發測試公司PRQA與Parasoft或多或少的讓開發者知道了單元測試框架的概念。相對于單元測試的需求，開發者暴露出來的測試問題，總結下來可以歸結五大漏洞。

1. 跟協作邏輯一起來測試算法。如果跟協作邏輯代碼分離開來，那么算法邏輯是最容易測試的。否則在你的邏輯被測試之前，你就不得不先進行諸如通過任務隊列提交一個任務之類的工作。 任務隊列部分只會使事情變得復雜。除非你想測試任務隊列本身，否則你就應當把調用run方法時所執行的邏輯剝離開來，并對它進行單獨測試。那樣，不論是編碼還是測試都會更易于編寫和管理。

2. Mock測試太多。也許單元測試的最大好處就是它迫使你編寫能夠獨立測試的代碼。也就是說，你的代碼會變得模塊化。當你把你要處理的對象的周圍的一切都模擬了，就沒有什么能迫使你去把各部分分離開來。你會發現這樣寫出的代碼，你很難在外圍添加獨立的部分 – 因為所有東西都糾纏在一起。

3. 不使用斷言。有時我會看到一些測試，里面創建了一個對象，調用了一些方法，然后，就沒有然后了。也許它是 在循環里這樣做的，而且在創建和調用上會有些差異。但是，卻沒有用斷言來做任何檢查。這就完全失去了意義 – 沒有檢查你的代碼是否按照預期進行工作的。當然，代碼是運行了，但是僅此而已。如果拋出了一個異常，我們會注意到它，但是卻不會驗證其它任何事情。

4. 在測試代碼中遺留print語句。我把這視為手工測試的后遺癥 – 你希望看到對象的值來判斷它們是否正確。但是所有的檢查都應當使用斷言來完成。如果單元失敗了，你也能看到它，因為這個測試也會失敗。當測試通過時，什么 也不應當打印出來。在編寫測試代碼時，使用print語句有時是有用的。但是在需要用print的地方應當設置一個標志位，用來在進行測試的時候屏蔽它。

5. 查看日志信息，而不是運行結果。 還好這并不普遍，但是我卻見過一個非常有能力的開發人員這么干過。要知道，真正重要的是方法的運行結果，而不是日志中都打印了什么，因為即使代碼中有錯誤，測試也可能會通過。

從總結的五大弊端來看，有思想上的滯后，有技術上的缺陷，有人為能力的限制等，當然還有很多，這五條是最常見或最難處理的。只能根據開發團隊自己內部調整，但也可以使用一定的測試工具（PRQA與Parasoft測試工具性價比非常高）。