代码之家 › 专栏 › 技术社区 › Serhat Ozgel

assert.areEqual失败,即使预期和实际相同

unicode .net

Serhat Ozgel · 技术社区 · 15 年前

下面的测试似乎产生了相同的字符串,但是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);
    }
}

压缩程序。压缩程序和压缩程序。解压缩程序使用gzipstream进行压缩和解压缩。

如果我尝试(65,90)而不是(256,65536),它就通过了,所以我猜它与Unicode有关。我尝试了currentculture和no-culture来代替invariantculture,但仍然失败。但得到的字符串似乎是相同的:

assert.areEqual失败。

预期:

实际情况:

我错过了什么?

4 回复 | 直到 13 年前

bzlm 13 年前

(char)(r.Next(256, 65536)) 可以产生无效的字符组合,导致未经编辑的文本,因此不能使用它来创建测试内容。这可能会发生,即使演员是有效的,并产生一个有效的字符。一个例子是u+d800到u+dfff中的代理,但可能还有其他代理。

如果要从所有unicode范围生成示例文本,则在创建示例文本时必须注意unicode,而不是将其随机转换为 char . (我认为当你在问题中说,当你为随机数提供一个更窄的范围时,它起作用时,你正好想到了这一点。)

Mitch Wheat 15 年前

使用 byte 不 char .

你的 Compress/Decompress 方法应该是 byte[] 数组,任何调用它们的函数都应该在调用它们之前读取unicode数据并翻译它。

您知道.NET2.0以后的版本包含 GZipStream 班级?

Stefan Steinegger 15 年前

做了一些实验:

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

这一次只测试一个字符,您没有随机值(没有“有时有效”的问题),您将看到是否有某种字符不起作用。

hoang 13 年前

我有相同的加密/解密测试。

使用二分法,我发现任何包含u+55296到u+57343范围内的unicode字符“代理代码点”的字符串都将无法使用assert.areEqual

所以你可以使用的最宽的范围是:

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

和

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