單元測試實踐的主要問題與解決(3)

2、  單元測試實踐的主要問題

    單元測試有個特色：測試簡單獨立的代碼很容易，但要在實際工做中作好單元測試卻很困難。

    根據咱們的經驗，企業在實施單元測試時，一般會面對四大問題——

•         不肯作：程序員沒有單元測試習慣。
•         沒時間：編寫測試代碼須要耗費大量的時間，項目的週期可能不容許。
•         作不了：代碼具備較高的耦合性，使單元測試難以進行。
•         作很差：測試效果不能使人滿意。咱們一般會以覆蓋率來衡量測試效果，但要實現高標準的測試覆蓋很困難。

 3、  解決思路和方法

    如何解決上述問題呢？接下來，談談一些思路和方法，使用的工具是Visual Unit。Visual Unit，簡稱VU，是可視化的C/C++單元測試工具。

3.1 如何解決「不肯作」和「沒時間」

    對於「不肯作」，咱們採用的對策是可視化，這個可視化，是指程序行爲可視，後面我會用案例來演示；對於「沒時間」，採用的對策是自動化，經過自動生成測試代碼、自動打樁等功能，讓測試的時間成本最小化。這二者結合起來，就是ETDD開發模式。

    那麼，ETDD是什麼呢？

    首先來介紹一下TDD，TDD就是測試驅動開發，這個你們可能聽得比較多了。ETDD就是Easy TDD，即：易行版的TDD。ETDD具備如下一些特色：

•         可視化，在開發過程當中，程序行爲可視。
•         自動化，除了測試數據須要人工設定外，其餘基本上都自動完成。
•         現實化，不必定要測試全部代碼，在開始階段，能夠只測試功能邏輯複雜的20%代碼。

    下面，我用一個案例，講解一下ETDD的過程：

    假如我要編寫一個函數，它的功能是刪除字符串左邊的空格。

    先寫好函數的框架，能經過編譯就行。在編寫代碼前，程序員必需要作的一件事情，是想清楚代碼的功能。若是咱們想的時候，順手把它記錄下來，就可讓代碼的功能更清晰、更明確。
    
    咱們如今來記錄代碼的功能。這裏的記錄，不是文字形式的寵統說明，而是數據形式的精肯定義，也就是用輸入和輸出的方式來記錄。
    首先，記錄最基本的功能，也就是最基本、最多見的輸入和輸出。輸入一個左邊有空格的字符串，輸出是刪除左邊空格後的字符串，返回值跟參數的輸出是同樣的。
    

    而後，記錄詳細的功能。例如，左邊沒有空格的，全是空格的，還有空字符串。
    
    把每種輸入的正確輸出也記錄一下。完成了這個工做後，代碼的功能就徹底定義下來了。
    
    如今，咱們開始編寫代碼。個人編碼思路是這樣的：分爲兩步，第一步計算左邊的空格數量；第二步，將非空格的字符向左移動，覆蓋掉左邊的空格。
    
    如下幾行代碼，計算左邊的空格，如今編譯一下。CTRL+F7。若是編譯經過，測試就會自動運行。
    
    咱們能夠看到，輸入是什麼，執行了哪些代碼，產生了什麼輸出。這裏，黑色的是當前輸入下所執行的代碼，未執行的話會顯示爲紅色。這裏全是黑色，表示當前輸入下執行了所有代碼。若是咱們想看一下計算左邊空格的結果對不對，這是內部的數據，要指定位置後纔會打印出來。按ESC鍵回到開發環境。
    
    用這種語法能夠輸出內部數據，適合於程序員開發過程當中使用。複雜類型也能夠用一樣的語法輸出。
    
    另外一種輸出內部數據的語法是，在左邊的代碼窗口，在要輸出的位置點擊一下，右鍵菜單選擇「輸出內部數據」，這樣填一下就好了。這種方式不會修改產品代碼，適合於測試員使用。
    
    再次執行後，能夠看到，左邊的空格的數量是4，這是對的，那咱們能夠繼續編寫。
        （待續）