2017-02-21 5 views
1

Ich habe den folgenden Unit-Test zu Test Datum Zeit Formatierung geschrieben:Warum schlägt Assert.AreEqual() für Zeichenfolge und DateTimeFormatter fehl?

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); 
     } 
    } 
} 

Ich verstehe nicht, warum die Behauptung mit dem folgenden Fehler fehl:

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

Ist dies, weil die Saiten anders haben Codierung?

Nachdem beide Strings in Byte-Arrays konvertieren UTF8 den Inhalt der Byte-Arrays Codierung sieht wie folgt aus:

aktuell:
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

erwartet: 54 68 75 72 73 64 61 79 2c 20 4d 61 72 63 68 20 32

+0

Was ist die Art von 'tatsächlichen'? –

+0

Strings hat keine Codierung, Codierung kommt ins Spiel, wenn Sie versuchen, eine Zeichenfolge in/aus Bytes zu konvertieren. –

+0

Versuchen Sie, sie als Bytearrays zu vergleichen, aus 'Encoding.UTF8.GetBytes (actual)' 'und ähnlich wie erwartet, sehen Sie, worüber sie sich beschweren. –

Antwort

2

Die Oktetts e2 80 8e zeigen, dass Sie haben mehrere U + 200E Zeichen im actual String. U + 200E ist ein Steuerzeichen zum Überschreiben des bidirektionalen Textalgorithmus und besteht darauf, dass das Folgende von links nach rechts geschrieben wird, auch wenn es sich um einen Fall handelt (z. B. hebräische oder arabische Zeichen), der normalerweise von rechts nach rechts geschrieben wird. links.

Die expected Zeichenfolge hat sie nicht.

Vermutlich wurde das Steuerzeichen entweder in Ihre Testdaten oder in die eigentliche Quelle des zu testenden Formatierers kopiert. In letzterem Fall sei froh, dass das Testen es fing. (Alternativ, vielleicht ist es aus irgendeinem Grund, dort zu sein).

+0

Da es die 'actual' -Variable ist, die diese Zeichen hat, sieht es so aus, als ob die Ausgabe von DateTimeFormatter diese Codepoints enthält. –

+0

@ LasseV.Karlsen machen die letzten zwei Vorschläge (dass es ein Fehler in DateTimeFormatter ist, oder dass es dort sein soll) die verbleibenden Möglichkeiten. –

Verwandte Themen