借助xUnit減少了生產問題

目錄介紹

背景使用**

興趣點考慮到使用

xunit

編寫許多測試的方式，需要改進兩件事：測試需要更加真實，並應防止日誌記錄受限。使測試更切合實際，將減少生產問題的可能性。此外，測試日誌記錄的內容可以避免在出現生產問題時必須限制日誌記錄細節來解決問題的問題。本文介紹了如何預防

xunit

測試中的此類問題。

生產問題是乙個眾所周知的問題。在大多數情況下，您不知道是什麼引起了問題，因此首先要做的是讀取日誌。閱讀日誌後，開發團隊可能會詢問以下問題：

為什麼沒有記錄我們期望記錄的物件？

為什麼我們找不到描述問題的警告或錯誤訊息？

為什麼我們找不到必須發生的異常？

為什麼我們的測試沒有失敗，因為有明顯的問題？

從tdd

的角度來看，需要進行兩項改進：

自動測試需要變得更加現實才能重現實際問題。

如果沒有

日誌記錄，則測試需要失敗。

本文介紹了如何執行此操作。

如果您以前曾經使用過

xunit

，這將非常有幫助，因為測試示例是基於

xunit

的。另外，

.net core

的一些經驗也很有幫助，因為這是我們在這裡使用的技術。

出於演示目的，我們使用了一種非常簡單的控制器方法。傳入的

value

包含firstname

，middlename

和lastname

以返回全名

}對於此方法，我們需要乙個可以檢測到記錄的測試：

invaliddataexception

，一些記錄訊息和

name

型別的資料物件。

此外，測試必須切合實際，這意味著它知道並使用設定依賴項的

startup

類。在常規的單元測試中，情況並非如此，但在針對

.net core

的整合測試中，情況從下面顯示的**中可以清楚地看出：

[fact]
public async task nomiddlenameputtest()
);        assert.equal(200, ((objectresult)response.result).statuscode);
assert.single(fixture.logsource.getwarnings());
var datalogged = fixture.logsource.getloggedobjects().tolist();
assert.single(datalogged);
assert.equal("f", datalogged.single().value.firstname);
assert.contains(fixture.logsource.getloglines(), a => a == "warning logged");
assert.contains(fixture.logsource.getloglines(), a => a.contains("this is the input"));
assert.single(fixture.logsource.getexceptions().oftype());
}}

fixture<>

類是從integrationfixture

的公開的

nuget

包。它使用

類（在此處

說明）來減少開發人員要編寫的樣板**。

在startup

類中設定的真實類依賴關係（不是模擬）用於使測試變得現實。

logsource

屬性使開發人員能夠呼叫返回我們關注的資料的方法（如記錄的資料物件，記錄的行和記錄的異常）。由於使用了真正的依賴關係，因此生產問題的可能性越來越小，因此這些問題很可能會在測試中涵蓋。此外，如果有生產問題，將有足夠的日誌記錄來幫助您解決問題，因為

xunit

測試將簡單地失敗並阻止部署，如果沒有足夠的日誌記錄，**可以在上..

獲得。

在編寫**時，我開始意識到自動化測試的重要性。作為開發人員，我們需要編寫用於

ci的整合測試，而不僅僅是單元測試。此外，我們不僅應該關注所需的功能，還應該關注日誌記錄。良好的日誌記錄對於快速解決生產問題至關重要，並且使用上述

nuget

軟體包，我們可以輕鬆地檢測出已記錄的內容。

借助xUnit減少了生產問題

單元測試 Xunit

xUnit 嘗試單元測試

在 Xunit 中使用依賴注入

借助xUnit減少了生產問題

單元測試 Xunit

xUnit 嘗試單元測試

在 Xunit 中使用依賴注入

相關推薦