测试失败由于不一致的 proto.Unmarshal

从现在开始，我们要努力学习啦！今天我给大家带来《测试失败由于不一致的 proto.Unmarshal》，感兴趣的朋友请继续看下去吧！下文中的内容我们主要会涉及到等等知识点，如果在阅读本文过程中有遇到不清楚的地方，欢迎留言呀！我们一起讨论，一起学习！

我有一些 redis 代码依赖于 proto 标准来编组/解组数据。我使用 gomega 编写了以下测试来测试 proto.unmarshal：

b64Decoded, err := base64.StdEncoding.DecodeString("derp")
Expect(err).ShouldNot(HaveOccurred())

var item testRecord
err = proto.Unmarshal(b64Decoded, &item)
Expect(err).Should(HaveOccurred())
Expect(err.Error()).Should(Equal("proto:\u00a0cannot parse invalid wire-format data"))

但是，最终断言失败，因为预期的错误字符串为 proto: 无法解析无效的有线格式数据。这里显而易见的解决方案是更改它，当我这样做时，错误就会消失。直到我修改测试并重新运行它，在这种情况下，测试再次失败，告诉我该字符串应该是 proto:\u00a0cannot parse invalid wire-format data。这个循环无限地持续下去。那么，我在这里做错了什么以及如何解决这个问题？

正确答案

这个问题并不完全像你想象的那样； protobuf 包在输出错误时随机选择一个空格或 \u00a0 （我相信它基于二进制文件的哈希）。你可以看到这个here：

// Deliberately introduce instability into the error message string to
// discourage users from performing error string comparisons.
if detrand.Bool() {
   return "proto: " // use non-breaking spaces (U+00a0)
} else {
   return "proto: " // use regular spaces (U+0020)
}

因此，您遇到的问题是故意的，旨在阻止用户执行您正在尝试的操作（依赖于错误保持不变）。您仅在更改测试时看到此内容的原因（并且我猜，不是每次更改它时）是 go 将缓存测试结果（默认情况下，仅在某些内容发生更改时才运行测试）。

就您可以采取的措施而言，我首先建议考虑是否确实有必要进行此测试。包作者特别指出错误并不稳定，因此当新版本的 google.golang.org/protobuf/proto 发布时，这种方式的比较可能会中断。

protobuf 包测试通过调用 detrand.disable()（例如 here）来解决此问题。您无法执行此操作，因为 google.golang.org/protobuf/internal/detrand 位于 internal 下，因此为 not accessible。

如果您确实想解决这个问题，最简单的方法可能是 strings.Contains。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《测试失败由于不一致的 proto.Unmarshal》文章吧，也可关注golang学习网公众号了解相关技术文章。