Assert.AreEqual失敗，即使預期和實際相同

我有以下測試似乎產生相同的字符串，但Assert.AreEqual失敗。Assert.AreEqual失敗，即使預期和實際相同

[TestMethod] 
public void Decompressed_test_should_equal_to_text_before_compression() 
{ 
    TextCompressor compressor = new TextCompressor(); 
    Random r = new Random((int)DateTime.Now.Ticks); 

    for (int i = 500; i < 1500; i++) 
    { 
     char[] testArray = new char[i]; 

     for (int j = 0; j < i; j++) 
     {      
      char randomChar = (char)(r.Next(256, 65536)); 
      testArray[j] = randomChar; 
     } 
     string testString = new String(testArray); 
     string compressed = compressor.Compress(testString); 
     string decompressed = compressor.Decompress(compressed); 

     Assert.AreEqual(testString.Length, decompressed.Length); 
     Assert.AreEqual(testString, decompressed, false, CultureInfo.InvariantCulture); 
    } 
}

compressor.Compress and compressor.Decompress使用GZipStream進行一些壓縮和解壓縮。

它通過，如果我嘗試（65,90），而不是（256,65536），所以我猜測它與unicode有關。我嘗試過CurrentCulture，根本沒有文化，而不是InvariantCulture，它仍然失敗。但由此產生的字符串似乎是相同的：

Assert.AreEqual失敗。

預計：

<☔ฺ疉鎷얚᧏跨꿌潙얫嘹֨ز항們嵜浮䑹شم靄斳薃픢萁⯬쫎ʛ⫕蝺ꄗ穌넢뇌䶆멊큀퉆䐫̥괊⑆놸僥̅ᵀ㣚ꢅ뺓䇚녚伀讍홬䈕캾撏Ჴ孢黮摠뮡䌦윃ᬳ狚䆙툾훶䏤ꛈṻ⟧㉖鮸蒵萗냤퇅서㪨瀲鰪殘䓴ۇ넃櫜㑦䢻쮓죣䕱䶘㴝姳뿝嘼ᷨ㗬꺬櫣涷꠶滸껅က㷕䩉毎覛⧹䮯嬇힚艐Ὑ쇕횻鸙蹻硐䈆쓖⸛錼鰙ኰ乒֐⺴썓힠䵓ꅄⵈ桃悵㾈枟⏠ه폫ا琖ퟰ乼쩐鑈푷᫇﯎蕱늛쭡䙠ⲓᒇꪮ툅⃑ꦴ돻♹ᢋ麝熪뚭Ћ䌚娯鈕⡃㪿ㅞ⤩㥍車䎘磛蚾ㅸ擫떦蝳分鰽䠺ꭍ튘폻⥽ⳉ歷⹼驛똮⯴⋟Ḋ᛼룴꣜墭䐣앾郢ᵸᮄ杗奪硼佑烑鄗䳘핬溴墽炁ࣘヲ栥풼ಃ鬥狹就쵎⃺嬒瀃碂밎崹䎐貇஛汫踖뢸숥퍞르뗿䭯䖝䱅䵱꽔븽䢴ꁅ⟼蒠癸ꩽ靝臨䚝！⩏￸鍁Ꮨ䷇쁐쨒ʊ쪦鄭借滋鉚ᮉ嚃ᩨ⶝ိ펇ꮼ뇄」ᰉ㕾椏鯅蛺䠿櫄築픆車똅렬㈆ّἋ蕎괋랆偦뤰䝷핸⹝屑素蝨懷猔勳碉퀪睹Ⓥ䍙ಗ䤮뾿謝ꁼ戻ڳᆯ콧逼ز븭碇쮢籍⁜왋壝罵暷샖଄ࣵ艫᜝䃴厫ᢉ慨䁆ꂴ೉溘欋옭螶䦗跠﨔膉痹邘⋫吪멚埣ꯕ扌옘廣犵肖街㶕暢몡ↇ꠫襤픧ၥ幘놤ਰ惘똞顫糴쫼鿋䬝獲⺁峁踷鍀副鰀嗊⹀譎遲䩢푑팾糔뭯዇ࣷ䷴䬾갭ⶵ틩魨㵻恬҅པᣄⲪ豩뛌꛵㥨몙〼△⏮큤亃ꢡ웼ఐ칇뻻펂㢓吋䂃䨠䕱>。

實際：

<☔ฺ疉鎷얚᧏跨꿌潙얫嘹֨ز항們嵜浮䑹شم靄斳薃픢萁⯬쫎ʛ⫕蝺ꄗ穌넢뇌䶆멊큀퉆䐫̥괊⑆놸僥̅ᵀ㣚ꢅ뺓䇚녚伀讍홬䈕캾撏Ჴ孢黮摠뮡䌦윃ᬳ狚䆙툾훶䏤ꛈṻ⟧㉖鮸蒵萗냤퇅서㪨瀲鰪殘䓴ۇ넃櫜㑦䢻쮓죣䕱䶘㴝姳뿝嘼ᷨ㗬꺬櫣涷꠶滸껅က㷕䩉毎覛⧹䮯嬇힚艐Ὑ쇕횻鸙蹻硐䈆쓖⸛錼鰙ኰ乒֐⺴썓힠䵓ꅄⵈ桃悵㾈枟⏠ه폫ا琖ퟰ乼쩐鑈푷᫇﯎蕱늛쭡䙠ⲓᒇꪮ툅⃑ꦴ돻♹ᢋ麝熪뚭Ћ䌚娯鈕⡃㪿ㅞ⤩㥍車䎘磛蚾ㅸ擫떦蝳分鰽䠺ꭍ튘폻⥽ⳉ歷⹼驛똮⯴⋟Ḋ᛼룴꣜墭䐣앾郢ᵸᮄ杗奪騑硼佑烑鄗䳘핬溴墽炁ࣘヲ栥풼ಃ鬥狹就쵎⃺嬒瀃碂밎崹䎐貇஛汫踖뢸숥퍞르뗿䭯䖝䱅䵱꽔븽䢴ꁅ⟼蒠癸ꩽ靝臨䚝！⩏￸鍁Ꮨ䷇쁐쨒ʊ쪦鄭借滋鉚ᮉ嚃ᩨ⶝ိ펇ꮼ뇄」ᰉ㕾椏鯅蛺䠿櫄築픆車똅렬㈆ّἋ蕎괋랆偦뤰䝷핸⹝屑素蝨懷猔勳碉퀪睹Ⓥ䍙ಗ䤮뾿謝ꁼ戻ڳᆯ콧逼ز븭碇쮢籍⁜왋壝罵暷샖଄ࣵ艫᜝䃴厫ᢉ慨䁆ꂴ೉溘欋옭螶䦗跠﨔膉痹邘⋫吪멚埣ꯕ扌옘廣犵肖街㶕暢몡ↇ꠫襤픧ၥ幘놤ਰ惘똞顫糴쫼鿋䬝獲⺁峁踷鍀副鰀嗊⹀譎遲䩢푑팾糔뭯዇ࣷ䷴䬾갭ⶵ틩魨㵻恬҅པᣄⲪ豩뛌꛵㥨몙〼△⏮큤亃ꢡ웼ఐ칇뻻펂㢓吋䂃䨠䕱>。

我錯過了什麼？

來源

2009-05-25 Serhat Ozgel

哇。對於我來說這兩個字符串是否一目瞭然一點也不明顯。 – 2009-05-25 15:27:20

哪些AreEqual失敗？ – 2009-05-25 15:27:23

@Stefan，第二個。 – 2009-05-25 15:31:02

(char)(r.Next(256, 65536))可以產生無效的字符組合，導致非法文本，所以你不能用它來創建測試內容。即使演員陣容有效並且製作了有效的角色，也會發生這種情況。其中一個例子是U + D800中的代替U + DFFF，但也可能有其他代碼。

如果您想要從所有Unicode範圍生成示例文本，則創建時必須注意Unicode，而不是僅將其隨機投射到char。（我想你偶然發現這個當你在問題中說，當你提供一個更窄的範圍內隨機數的工作。）

來源

2009-05-25 15:31:01 bzlm

使用byte不是char。

您的Compress/Decompress方法應採用byte[]數組，無論調用它們應該讀取您的Unicode數據並在調用它們之前進行翻譯。

您知道.NET 2.0以上版本包含GZipStream類嗎？

來源

2009-05-25 15:27:54

提出了一些實驗：

string testString = new String(testArray); 
string anotherString = new String(testArray); 
Assert.AreEqual(testString.Length, anotherString.Length); 
Assert.AreEqual(testString, anotherString, false, CultureInfo.InvariantCulture);

這是一個沒有壓縮。它工作正常。

我建議您到考試改成這樣：

for (int i = 256; i < 65536; i++) 
{ 
    string testString = new String((char)(i), 2); 

    string compressed = compressor.Compress(testString); 
    string decompressed = compressor.Decompress(compressed); 

    Assert.AreEqual(testString.Length, decompressed.Length); 
    Assert.AreEqual(testString, decompressed, false, CultureInfo.InvariantCulture); 
}

這一次測試的一個字符，你沒有隨機值（無「有時是作品」的問題），你會看看是否有某種不起作用的字符。

來源

2009-05-25 15:47:01

我有相同的加密/解密測試。

使用二分法，我發現，含有「代孕代碼點」的任何字符串，它是在範圍Unicode字符U + 55296至U + 57343將無法使用Assert.AreEqual

使最廣泛的範圍內可以使用分別是：

char randomChar = (char)(r.Next(0, 55295));

和

char randomChar = (char)(r.Next(57344, 65535));

來源

2011-09-28 12:06:06 hoang

Assert.AreEqual失敗，即使預期和實際相同

回答

相關問題