開發和測試工程師寫代碼的高下之分

 有來面試的同行問個一個問題：“如果微軟的開發和測試工程師都需要寫代碼，那么兩者寫出來的代碼有高下之分嗎？”
        當時我只能簡單的解釋一下?，F在可以多說一些了。
        舉個例子，單元測試。適合不同語言的工具有一大堆，各個論壇上都能搜到大堆文章。出現頻率最高的不外乎CppUnit，NUnit，JUnit三種。比起NUnit和JUnit，CppUnit因為C++語言特性的關系，用起來較不方便。
        這里我給大家秀一下，解決這個問題，測試工程師會如何的“不擇手段”。
        單元測試往往需要解決以下幾個問題：
        1.     用戶能在產品代碼中指定需要測試的函數
        2.     用戶能在測試代碼中指定需要執行的函數
        3.     用戶能指定各種控制執行過程的參數，比如優先級、重復、初始化/清理函數等等
        其它就先不說了，待會大家就知道再多的都能做到，現在先做到這三個需求就挺不錯了。需求1是可選的。Visual Studio從2005開始有這個功能，但是如果沒有，估計大家也不會太在意，對吧？
        那么，CppUnit如果要做到NUnit和JUnit的樣子會遇到什么困難呢？首先就是C++缺乏反射（Reflection）功能。
        你看NUnit和JUnit都是定義了一大堆attribute。用戶通過為函數指定恰當的attribute，就能標明這個函數需要作為test case執行，之前執行初始化函數Setup，之后執行Cleanup，還有重復100次，優先級2什么的，其它的往上堆attribute就行了。
        Visual Studio 2005之后為實現需求1，通過.NET Reflection找出一個類的全部成員函數，然后列個表讓你選要測試的函數，最后代碼架子都給你搭好。
        而CppUnit得用模板，還有另外一個我忘了名字的C++單元測試工具用的是宏。他們費這么些勁是為了什么呢？其實是為了取得這些信息：
        具有特定標記的函數的名字或者入口地址/函數指針
        附加在該函數上的各種整數，字符串或者函數指針的值
        拿到之后呢？CppUnit也好，NUnit或JUnit也好，都是按照取得的信息規劃每個函數的執行，保證異常和錯誤不干擾其它函數的執行，統計整理執行結果和記錄日志，沒什么區別。
        我們來看看，Reflection對于取得那些信息是不是必需的呢？
        沒錯，Reflection是能夠在執行時（runtime）取得上述信息，然后在執行時利用它指導test case的執行。
        等等，我雞蛋里挑個骨頭：非要把“取得信息”和“指導test case執行”放在同一段執行時期里面嗎？或者說，先“取得信息”，停一下，再“指導test case執行”，行不行？
        甚至，“取得信息”放在一個程序里先執行，“指導test case執行”放在另一個程序里后執行，又如何？
        更甚之，“取得信息”是讓別的程序做的，之后讓“指導test case執行”撿現成的呢？
        可見，Reflection提供了比我們所需要的多得多的功能，實際上我們只需要知道“怎樣指導test case執行”就夠了。
        那可以如何實現呢？
一、     編譯鏈接兩次
        對，你沒聽錯！編譯鏈接之后除了可執行文件還會產生不少有用信息，最有用的當屬PDB文件，包含了所有標識符（Symbol）的信息。Visual Studio 2003開始就帶有一個DIA SDK，可以在其安裝目錄的DIA SDK文件夾下面找到頭文件、庫文件、COM組件DLL和示例程序。用它分析一個DLL或者EXE可執行文件對應的PDB文件，你可以取得每個編譯單元（用.c/.cpp編譯得到的obj或者lib）里全部函數的情況，包括函數名字、是否成員函數、返回類型、全部參數的名字和類型、全部局部變量的名字和類型，甚至它在哪個文件的哪一行定義。
        在這些信息中可以過濾出用戶預先指定的信息，用來拼成另一個C/C++源文件，這個源文件叫做執行表，里面包含了所有需要執行函數的名字列表以及各項參數的靜態定義?！爸笇est case執行”是可以預先分離實現的模塊，把它include進來即可。最后，把原先用來產生可執行文件的全部文件，把定義main或者DllMain的那個源文件，改為執行表，再編譯鏈接一次，大功告成。
      

原文轉自：http://www.kjueaiud.com