單元測試小技巧[5]

　　單元測試小技巧[5]  軟件測試

　　需要注意的是，我已經在前面分別實際演示了通過在不同行中創建一個結果變量的方法從聲明操作中進行分解操作。這樣做至少有兩個理由。第一個理由是，你可以為一個變量分配一個可讀性強的名字，它可以包含結果，這樣可以使你的聲明行非常易于理解以及易于讀。第二點是，測試下與對象相反的invocation 可能非常的長，它可能會使你的聲明行延伸出屏幕的邊緣之外，這樣導致測試者向右滾屏。就我個人而言，我認為這個是非常惱人的。

　　我在我的測試中使用了很多常量以確保我的聲明讀起來像一本書。在先前的例子之中，你可以讀到聲明中說：“確保分解總數是與忽略第一個數后所得總和是相等的?！?為你的變量取一個很好的名字能夠在某些程度上彌補對于測試的命名不足。

　　當然，有時一個聲明 消息是在一個單元測試中傳遞intent的最好的方法。 一個好的聲明消息始終能夠解釋什么因該會發生或者什么發生了而且為什么會出錯。舉個例子來說，“分列應該忽略掉第一個數字如果這個數字是個負數的話”，“分列不能夠忽略掉第一個負數”，還有“X調用對象Y標記錯誤”這些都是有用的聲明消息，它們很清晰的描述了結果的情況。

　　在你的設置方法中避免部分相關的代碼

　　一個 方法是樣例成員變量在測試中使用的一個好地方。你所有的測試，只有在一部分的測試中避免變量。他們可以為測試設置本地變量。如果你創建了部分相關的實例作為類的成員，用來在測試中簡單的避免創建的副本，你應該使用在文章前面解釋的工廠方法，使用部分相關變量使得你的代碼和設置方法缺少易讀性。一旦變量在一個或者每個測試中使用，那么他應該是 方法的一個成員和變量。

　　Figure 5 展現了一個擁有兩個成員變量的類的測試。但是他們中的一個(cxNum)只被部分使用。Figure 6 展現了如何在測試中替換代碼從而使它更加易讀的方法。

　　總結

　　就像你所看到的，寫單元測試并不是一個微不足道的任務，如果步驟正確，單元測試可以為開發者的生產力和代碼的質量帶來令人驚訝的提高，他可以幫助你去創建的應用程序含有更少的錯誤，同時也可以便于其他的開發者去洞察你的代碼，但是他也需要在之前承擔一個義務，確認遵循一些簡單的規則。當方法并不是很好時，單元測試則可能達到一個相反的結果，從而浪費您的時間，并且使測試過程更加復雜。

　　Roy Osherove Agile組的負責人, 這個顧問公司致力于agile software development 和 .NET architecture的研究工作. Roy同時維護了一個blog在 www.iserializable.com上有相關的信息. 你可以通過Email聯系他： Roy@TeamAgile.com.

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