練習修正失敗的測試

此時，您可以在透過組建管線移動變更時，執行單元測試。您也可以使用方法來測量測試所涵蓋的程式碼數量。

最好一律在本機執行測試，再將變更提交至管線。但是當有人忘記並提交中斷組建的變更時，會發生什麼事？

在此單元中，您將會修正因失敗單元測試所造成的中斷組建。在這裡，您將會：

小組的最新功能只涵蓋排行榜。我們需要從資料庫取得分數，因此，我們可以撰寫單元測試來驗證IDocumentDBRepository.GetItemsAsync方法。

測試看起來像這樣。您還不需要新增任何程式碼。

[TestCase(0,ExpectedResult=0)][TestCase(1,ExpectedResult=1)][TestCase(10,ExpectedResult=10)]publicintReturnRequestedCount(intcount){constintPAGE=0;//takethefirstpageofresults//Fetchthescores.Task>scoresTask=_scoreRepository.GetItemsAsync(score=>true,//returnallscoresscore=>1,//wedon'tcareabouttheorderPAGE,count//fetchthisnumberofresults);IEnumerablescores=scoresTask.Result;//Verifythatwereceivedthespecifiednumberofitems.returnscores.Count();}回想一下，在NUnit測試中，TestCase提供要用來測試該方法的內嵌資料。NUnit會呼叫ReturnRequestedCount單元測試方法，如下所示：

ReturnRequestedCount(0);ReturnRequestedCount(1);ReturnRequestedCount(10);此測試也會使用ExpectedResult屬性來簡化測試程式碼，並協助清除其意圖。NUnit會自動比較傳回值與這個屬性的值，而不需明確地呼叫判斷提示。

我們會選擇數個值來表示一般查詢。我們也會納入0，以涵蓋該邊緣案例。

如同您先前所執行的，從GitHub擷取failed-test分支，並簽出(或切換至)該分支。

假設您最後並未再次執行測試，就匆促地將工作向上推送。幸運的是，管線可協助我們在進行單元測試時及早揪出問題。您將在這裡看到該問題。

實務上，您永遠都不會在組建執行時手動追蹤它們。以下提供您可能用來探索失敗的數種方式：

當單元測試失敗時，視失敗的本質而定，您通常會有兩個選擇：

在本節中，您將在本機重現失敗。

您注意到每個失敗的測試都會產生差一的結果。例如，預期10時，測試便會傳回9。

查看所要測試方法LocalDocumentDBRepository.GetItemsAsync的原始程式碼。您應該會看到以下內容：

publicTask>GetItemsAsync(FuncqueryPredicate,FuncorderDescendingPredicate,intpage=1,intpageSize=10){varresult=_items.Where(queryPredicate)//filter.OrderByDescending(orderDescendingPredicate)//sort.Skip(page*pageSize)//findpage.Take(pageSize-1);//takeitemsreturnTask>.FromResult(result);}在此案例中，您可以檢查GitHub，以查看檔案最近是否變更。

您懷疑pageSize-1所傳回的結果數目少了一個，而這應該只是pageSize。在我們的案例中，這是您推送工作而不進行測試時所犯的錯誤，但在真實案例中，您可以洽詢在GitHub上變更檔案的開發人員，以判斷變更的原因。

提示

討論與共同作業也可能會在GitHub上發生。您可以在提取要求上加上註解，或提出問題。

在本節中，您會藉由將程式碼變更回其原始狀態，並執行測試以確認修正來修正此錯誤。

太棒了！您已修正組建。接下來，您將會了解如何清除AzureDevOps環境。