第第頁單元測試小技巧[1]單元測試小技巧[1]

發(fā)表于：2023-06-01來源：：點擊數(shù)：標簽：單元技巧

單元測試小技巧[1]軟件測試-編寫可維護的節(jié)省時間和精力的單元測試這篇文章描述了：單元測試的信任測試正確事件創(chuàng)建維護測試創(chuàng)建易讀測試這些天有很多的關于單元測試的和在不同的場景下為他們的應用程序編寫單元測試(起始于,我們2023年六月的MSDNM

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

-編寫可維護的節(jié)省時間和精力的單元測試

這篇文章描述了：

單元測試的信任

測試正確事件

創(chuàng)建維護測試

創(chuàng)建易讀測試

這些天有很多的關于單元測試的和在不同的場景下為他們的應用程序編寫單元測試(起始于,我們2023年六月的MSDNMagazine中有關測試你的數(shù)據(jù)層的文章,KnowThyCode:SimplifyDataLayerUnitTestingusingEnterpriseServices)的討論。這些意味著有很多的開發(fā)者自言自語(或者對于他們的團隊)到：“哎，我們也需要開始編寫測試了!”因此他們開始編寫單元測試上面的單元測試直到他們達到了一個測試自己已經(jīng)成為問題的程度?；蛟S維護他們是一個太過困難，花費太長時間，或者他們并沒有足夠的易讀性以便于理解，更或者他們本身存在bugs有一點是能夠使得我們的開發(fā)人員可以下定決心去做的，那就是：花費他們寶貴的時間以用來改進提高他們的測試或者忽略其中的問題,從而有效的甩掉那些艱苦的工作。而這些困難的原因僅僅是因為那些不熟練的寫入單元測試。.在這篇文章中，我將為大家?guī)碓谶^去一年多時間里我在開發(fā)，提供咨詢和培訓開發(fā)者等方面有總結出來的一些最重要的練習和試驗。這些小的技巧可以幫助您寫出更有效的，可維護，和魯棒性更好的單元測試。同時我希望這些總結和忠告可以幫助您避免一些由于錯誤引起的大量的時間的消耗。

單元測試的信任

在這個部分，我將略述出一些最通用的信任，這些信任來自于在使用大量單元測試獲得的好處和解釋為什么這些信任通常不是必須真實的。然后我們會幫助您在您的工程中擁有這些信任。

更加簡單的跟蹤Bug當然這并不是必須的，那么您怎么知道您的測試是正確的?是否存在在一些測試環(huán)節(jié)測試失敗的情況?另外您又如何知道您的測試覆蓋了系統(tǒng)中多少的代碼量?是否測試到了程序中的錯誤，錯誤又在哪里等等的問題。

當你在你的單元測試中發(fā)現(xiàn)了bug后又會發(fā)生什么事情哪?你會突然間得到很多與愿意錯誤的反饋，bug被發(fā)現(xiàn)，但是問題并不在你測試的代碼中。你的測試的邏輯存在一個bug，因此測試失敗了。這些bug也是您最難被檢查出來的，因為您通常會去檢查您的應用程序而不會去檢測你的測試環(huán)節(jié)。在這部分中，我會展示給你如何確認大量的單元測試，事實上就是使得跟蹤bug變得更加容易。

代碼更加便于維護從最終點考慮，你可以傾向于認為這些信任并不是必須的，當然你是對的，讓我們?nèi)フf，代碼中每個邏輯方法至少要有一個測試方法(當然，你可能擁有一個以上的方法)在一個好的測試覆蓋的工程中，大概有百分之六十的代碼是能夠得到單元測試的，現(xiàn)在不得不考慮到測試也是要被維護的，如果針對一個復雜的邏輯方法你有20個測試，那么當你向這個方法添加一個參數(shù)時會發(fā)生什么事情哪?測試無法編譯。當你修改了類的結構的時候同樣會發(fā)生這樣的事情。這時你突然發(fā)現(xiàn)為了能讓你的應用程序繼續(xù)工作你自己需要改變大量的測試。當然這會花費你大量的時間。

為了使這個信任確認下來，你需要確認你的測試是便于維護的。保持DRY規(guī)則寫入：不要重復你自己。我們將更加接近的來看這個問題。

代碼更加容易被理解單元測試的好處通常并非是人們最初所期待的，在一個工程中考慮修改一些你之前從沒有看過的代碼(比方說,一個特殊的類或者方法).你將如何動手處理這些代碼?你可能需要在項目中去瀏覽這些特定的類或者方法使用的代碼，理所當然，單元測試就是這樣例子的一個很好的場所。同時，當正確寫入的時候，單元測試可以為工程提供一個API文件的容易讀取的設置，使得文檔的處理和代碼的理解對于整個團隊中的新老開發(fā)者一樣的簡單，便捷。然而，這些只能在測試是易讀的和容易理解的情況下才能被確認，這個規(guī)則很多的單元測試開發(fā)者并不會遵循。我將詳述這個信任，然后在這篇文章的易讀測試的部分給你展現(xiàn)如何在去寫易讀的單元測試。

測試正確的事情

新來者在TestDrivenDevelopment(TDD)中一個最通常的錯誤就是他們通常會搞混"Failbytestingsomethingillogical."中的"Failfirst"要求。例如，你可以用下面的規(guī)格開始這個方法：clearcase/"target="_blank">cccccc>'returnsthesumofthetwonumbers

FunctionSum(ByValaAsInteger,ByValbAsInteger)AsInteger你可以向如下的方式寫一個失敗測試：TestMethod()_

PublicSubSum_AddsOneAndTwo()

DimresultAsInteger=Sum(1,2)

Assert.AreEqual(4,result,"badsum");

EndSub初看上去這個處理像是一個寫失敗測試的好的方法，它完全錯失了你寫錯誤測試的初始點。

一個失敗測試驗證了在代碼中存在一些錯誤，當你的測試完成后這個測試應該是通過的，現(xiàn)在的例子中，無論如何，測試都將會失敗，即使是代碼完成