为什么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失败？

回答

相关问题