來源: WingFire On Toplanguange
1.單元測試庫要盡量少地增加開發(fā)人員的負擔。額外負擔必須盡可能直白，傻瓜化。
市面上的許多講到單元測試的書都是以XUnit為藍本的，這導致CppUnit的接受程度頗高。CppUnit中規(guī)中矩，四平八穩(wěn)，但不夠犀利。個人認為boost.test最簡單，只要一個BOOST_AUTO_TEST_CASE就可以開始了。CppUnit則要復雜一點，而這種復雜性是多余的，甚至是有害的。用CppUnit的時候，我看到有人為了共享測試代碼，隨便在test case里面加函數(shù)，然后復用，結果導致case不獨立。boost.test傾向于不要建立.h文件，所以要復用不方便（或者，不習慣在Cpp中復用），反而不容易犯錯誤。
2.實施單元測試，必須能夠讓程序員看得到好處并盡快受益。新項目必須盡早引入單元測試，要早在正式編碼之前。
想立刻讓UT變得完美是不可能的，行政命令也不會有好結果。在推行單元測試的時候，教育很重要。必須讓同事能理解單元測試為什么有效，如何工作，UT編寫準則之類的問題。另外，在工作多年的程序員（對UT缺乏認識的）中推行單元測試，阻力更大。更要注意教育和反饋。最好的反饋就是幫助他們從單元測試中獲益。例如，修改更輕松，思維更面向接口，bug更少，代碼更容易理解等等。作為推動者，有義務去主動發(fā)現(xiàn)這些改善之處并積極地反饋給程序員。從而增強應用UT的信心和意愿。
3.必須充分自動化。
UT的任務之一是給代碼編織一層細密的保護網(wǎng)。程序員應該認識到，單元測試是為自己服務的，所以，我們要的是完成任務而不是展示。能夠自動地完成任務則是最好的。如果單元測試過多地干擾程序員的正常思考，就會招致更多的抵觸（抵觸總是存在的）或敷衍。敷衍是可怕的。我向來是把單元測試的運行作為build的一個步驟的。成功的單元測試不需要輸出任何信息，最多在全部passs的時候給個OK就足夠了。圖形界面的測試工具在我看來也是雞肋，新手的玩具而已。圖形界面既不利于參數(shù)化運行，也不方便自動化，實在是降低開發(fā)效率的殺手。
4.不要追求完美的UT。
不是所有東西都很容易測試。UT要求被測試的東西可重現(xiàn)，可觀測。 基本上，大部分的物理操作因為缺乏可重復性或可觀察性，很難測試，例如database，GUI （注意，這不意味著在實現(xiàn)一個GUI庫或db driver時就不能做UT了）。勉強UT全覆蓋，既不現(xiàn)實，也不實惠。并且，這很可能讓UT變得復雜，高成本，這是非常危險的和不值得的。我的主張是，很難測，那就不測，但要正確應對。我的做法是將難測的部分隔離到一些抽象層當中去。然后為這些抽象層寫MockObject即可測試了。我曾經(jīng)應用在數(shù)據(jù)庫應用中，并很自然的得到一個良好的數(shù)據(jù)訪問的抽象層，單元測試就只測了這個抽象層。而實際的數(shù)據(jù)庫訪問中的物理操作部分，則從單元測試中剝離出去。如果堅持分離物理操作和邏輯操作的話，這個剝離出去的部分一般很小很有限，也很容易測試。相反，如果不剝離，將導致單元測試的結果要依賴數(shù)據(jù)庫的狀態(tài)。這種額外的依賴性沒什么好處。這里的關鍵是，必須讓不可測的部分盡可能隔離，盡可能小，盡可能地將邏輯操作從物理操作中分離出來。被隔離部分所包含的邏輯操作仍然需要寫UT。