復雜的東西寫多了，如今寫點簡單的好了。由于功能上的需要，Vczh Library++3.0被我搞得很離譜。為了開發維護的遍歷、減少粗心犯下的錯誤以及增強單元測試、回歸測試和測試工具，因此記錄下一些開發上的小技巧，以便拋磚引玉，造福他人。歡迎高手來噴，菜鳥膜拜。

    之前的文章講了指針和內存的一些問題，今天說一下單元測試的問題。如果在團隊里面沒有對單元測試的框架有要求的話，其實我們可以使用一個最簡單的方法來搭建在IDE里面運行的單元測試框架，整個框架只需十幾行代碼。我們先來考慮一下功能最少的單元測試框架需要完成什么樣的內容。首先我們要運行一個一個的測試用例，其次在一個測試用例里面我們要檢查一些條件是否成立。舉個例子，我們寫一個函數將兩個字符串連接起來，一般來說要進行下面的測試：

    如果我們的單元測試框架可以這么寫，那顯然做起什么事情來都會方便很多，而且不需要向一些其他的測試框架一樣注冊一大堆東西，或者是寫一大堆配置函數。當然這次我們只做功能最少的測試框架，這個框架除了運行測試以外，不會有其他功能，譬如選擇哪些測試可以運行啦，還是在出錯的時候log一些什么啦之類。之所以要在IDE里面運行，是因為我們如果做到TEST_ASSERT中出現false的話，立刻在該行崩潰，那么IDE就會幫你定位到出錯的TEST_ASSERT中去，然后給你顯示所有的上下文信息，譬如說callstack啦什么的。友好的工具不用簡直對不起自己啊，干嗎非得把單元測試做得那么復雜捏，凡是單元測試，總是要全部運行通過才能提交代碼的。

    那么我們來看看上面的單元測試的代碼。首先寫了TEST_CASE的那個地方，大括號里面的代碼會自動運行。其次TEST_ASSERT會在表達式是false的時候崩潰。先從簡單的入手吧。如何制造崩潰呢？最簡單的辦法就是拋異常：

    這里面有兩個要注意的地方。首先e要加上小括號，不然取反操作符就有可能做出錯誤的行為。譬如說當e是a+b==c的時候，加了小括號就變成if(!(a+b==c))...，沒有加小括號就變成if(!a+b==c)...，意思就完全變了。第二個主意的地方是我使用do{...}while(0)把語句包圍起來了。這樣做的好處是可以在任何時候TEST_ASSERT(e)都像一個語句。譬如我們可能這么寫：

    如果沒有do{...}while(0)包圍起來，這個else就會被綁定到宏里面的那個if，你的代碼就被偷偷改掉了。

    那么現在剩下TEST_CASE(x){y}了。什么東西可以在main函數外面自動運行呢？這個我想熟悉C++的人都會知道，就是全局變量的構造函數啦。所以TEST_CASE(x){y}那個大括號里面的y只能在全局變量的構造函數里面調用。但是我們知道寫一個類的時候，構造函數的大括號寫完了，后面還有類的大括號，全局變量的名稱，和最終的一個分號。為了把這些去掉，那么顯然{y}應該屬于一個普通的函數。那么全局變量如何能夠使用這個函數呢？方法很簡單，把函數前置聲明一下就行了：

    那我們來看看TEST_CASE(x){y}究竟會被翻譯成什么代碼：

    到了這里是不是很清楚了捏，首先在main函數運行之前TESTCASE_RUNNER_x_INSTANCE變量會初始化，然后調用TESTCASE_RUNNER_x的構造函數，最后運行函數TESTCASE_x，該函數的內容顯然就是{y}了。這里還能學到宏是如何連接兩個名字成為一個名字，和如何寫多行的宏的。

    于是MyUnittestFramework.h就包含這兩個宏，其他啥都沒有，是不是很方便呢？打開Visual C++，建立一個工程，引用這個頭文件，然后寫你的單元測試，最后F5就運行了，多方便啊，啊哈哈哈。

    這里需要注意一點，那些單元測試的順序是不受到保證的，特別是你使用了多個cpp文件的情況下。于是你在使用這個測試框架的同時，會被迫保證執行一次單元測試不會對你的全局狀態帶來什么副作用，以便兩個測試用例交換順序執行的時候仍然能穩定地產生相同的結果。這對你寫單元測試有幫助，而且為了讓你的代碼能夠被這么測試，你的代碼也會寫的有條理，不會依賴全局狀態，真是一舉兩得也。而且說不定單元測試用例比你的全局變量的初始化還先執行呢，因此為了使用這個測試框架，你將會不得不把你的全局變量隱藏在一個cpp里面，而暴露出隨時可以被調用的一組函數出來。這樣也可以讓你的代碼在使用全局狀態的時候更加安全。

    今天就講到這里了。下一篇要寫什么我還沒想好，到時候再說吧。