爲什麼Assert.AreEqual（）對字符串和DateTimeFormatter失敗？

我寫了下面的單元測試，以測試日期時間格式：爲什麼Assert.AreEqual（）對字符串和DateTimeFormatter失敗？

using System; 
using Windows.Globalization.DateTimeFormatting; 
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework; 

namespace MyTests 
{ 
    [TestClass] 
    public class DateTimeFormatterTests 
    { 
     [DataTestMethod] 
     [DataRow(2, 3, 2017, "en", "Thursday, March 2")] 
     [DataRow(2, 3, 2017, "de", "Donnerstag, 2. März")] 
     public void Long_date_without_year_should_match_expected(int day, int month, int year, string regionCode, string expected) 
     { 
      DateTimeFormatterformatter = new DateTimeFormatter("dayofweek month day", new[] { regionCode }); 
      string actual = formatter.Format(new DateTime(year, month, day)); 
      Assert.AreEqual(expected, actual); 
     } 
    } 
}

我不明白爲什麼斷言失敗，出現以下錯誤：

{"Assert.AreEqual failed. Expected:<Thursday, March 2>. Actual:<‎Thursday‎, ‎March‎ ‎2>. "}

這是因爲串具有不同編碼？

轉換兩個串成使用編碼字節數組的內容UTF8字節數組後看起來像這樣：

實際：
e2 80 8e 54 68 75 72 73 64 61 79 e2 80 8e 2c 20 e2 80 8e 4d 61 72 63 68 e2 80 8e 20 e2 80 8e 32

預期： 54 68 75 72 73 64 61 79 2c 20 4d 61 72 63 68 20 32

來源

2017-02-21 Martin Komischke

'actual'的類型是什麼？ –

字符串沒有編碼，編碼在您嘗試將字符串轉換爲字節時發揮作用。 –

嘗試將它們作爲字節數組進行比較，從'Encoding.UTF8.GetBytes（actual）'和類似的期望值中查看它所抱怨的內容。 –

這些八位組e2 80 8e表明在actual字符串中有幾個U + 200E字符。 U + 200E是一種用於覆蓋雙向文本算法的控制字符，並且堅持以下內容從左到右書寫，即使它是一種通常會被寫入右對齊的情況（例如希伯來文或阿拉伯文字符）剩下。

expected字符串沒有它們。

假定控制字符被複制到您的測試數據或您正在測試的格式化程序的實際源中。在後一種情況下，高興的測試抓住了它。（或者，也許它是出於某種原因在那裏）。

來源

2017-02-21 11:18:37

由於它是具有這些字符的'actual'變量，因此它看起來像包含這些代碼點的DateTimeFormatter的輸出。 –

@ LasseV.Karlsen提出了最後兩條建議（即它是DateTimeFormatter中的一個錯誤，或者它意味着存在）剩下的可能性。 –

爲什麼Assert.AreEqual（）對字符串和DateTimeFormatter失敗？

回答

相關問題