比較包含C＃格式的字符串

Question

我正在使用具有某些設置的函數-例如行距，修改了輸出（以字符串形式）。 為了測試這種情況，我使用字符串文字，如下所示以獲得預期的結果。

該方法使用字符串構建器（ AppendLine ）生成上述輸出。 我遇到的一個問題是比較這樣的字符串。 在下面的示例中，兩者在表示上是相等的。 結果是我關心的領域，但是當比較兩個字符串時，一個文字，一個不是，相等自然會失敗。 這是因為其中一個字符串發出行距，而另一個僅演示其包含的格式。

解決這個平等問題的最佳方法是什么？ 我確實關心從方法結果中格式化新行的格式，這一點至關重要。

碼：

string expected = @"Test\n\n\nEnd Test.";
string result = "Test\n\n\nEnd Test";

Console.WriteLine(expected);
Console.WriteLine(result);

輸出：

Test\n\n\nEnd Test.
  Test


  End Test

Answer 1

@前綴告訴編譯器完全按照寫入的方式獲取字符串。 因此，它不會將\\n字符格式化為回車符和換行符。

由於分配給結果變量的字符串沒有相同的前綴，因此編譯器會對其進行格式化。 如果您想繼續使用@前綴，請執行以下操作：

    string expected = @"Test


End Test";

您必須在字符串中輸入回車符和換行符作為不可見的字符。

Answer 2

您錯誤地使用了“文字”一詞​​。 “文字”僅表示代碼中存在的實際值。 換句話說，值在代碼中既可以作為變量 （為簡單起見，在此組中包括常量）也可以作為文字存在 。 變量是一個值的一個抽象的概念 ，而文字是一個值 。

這就是說，您的兩個字符串都是字符串文字，因為它們都被硬編碼到您的應用程序中。 @前綴只是說明編譯器將在字符串中包含轉義字符（實際上，除了雙引號之外的任何東西），而不是在將字符串文字編譯到程序集中時評估轉義序列。

首先， 無論您的函數返回什么（包含換行符而不是換行符的標准轉義序列的字符串，或者實際上包含換行符的字符串）都是測試變量應包含的內容 。 使您的測試盡可能接近實際輸出，因為您做更多的工作來將值壓縮為可比較的形式，因此您必須測試的代碼路徑也就更多。 如果您希望能夠將具有嵌入其中的格式化轉義序列的字符串與已評估了這些序列的字符串進行比較（本質上是比較示例中的兩個字符串），那么我會這樣說：

1. 確保這確實是您想要的。
2. 在解釋這些值並將“格式字符串”轉換為“ 格式字符串”時，您將不得不復制C＃編譯器的功能。

對於執行＃2，RegEx處理器可能將是最簡單的選擇。 有關C＃字符串轉義序列的列表，請參見此頁面 。

Answer 3

我感到有些開悟，但對發現的內容感到惱火。

這是我的第一個使用MSTest的項目，測試失敗后，我選擇了“ 查看測試詳細信息”以查看測試失敗的方式和原因。 此詳細信息顯示中字符串輸出的格式非常差，例如，您得到：

Assert.AreEqual failed. Expected:<TestTest End>. Actual:<TestTest End>.

這是用於格式化的文本-奇怪的是，如果您使用/r （換行符）而不是換行符（ /n ），則格式化實際上是正確的。

原來是查看在調試模式下運行測試所需的正確輸出。 換句話說，當您的測試失敗時，請在debug中運行測試，異常將被捕獲並顯示如下：

Assert.AreEqual failed. Expected:<Test


Test End>. Actual:<Test


 Test End>.

上面顯然包含正確的格式。

最后，事實證明，我最初將期望（使用格式）存儲在字符串中的方法是正確的，但是我對MSTest的不熟悉使我質疑我的意思，因為它似乎是有效的輸入，但只是向我顯示了什么內容。出現了有效的輸出。

Answer 4

在進行比較之前，使用正則表達式刪除空白嗎？