如何测试Kryo避难所不兼容的Scala类
我想使用Kryo来序列化和对类的层次结构进行序列化，例如：
case class Apple(bananas: Map[String, Banana], color: Option[String])
case class Banana(cherries: Seq[Cherry], countryOfOrigin: String)
case class Cherry(name: Option[String], age: Int, isTomato: Boolean)
有时我想在此层次结构中的某个地方添加和删除字段，例如cherry。
我想编写一个单位测试，该单元测试查看以Apple开始的类型层次结构，并得出结论，以前与Kryo序列化的数据不会正确地序列化 - ie值得序列化的对象不会是== <== < /代码>到序列化对象，如果我可以同时在内存中都有两个。
在这种情况下，我可以在Redis缓存中更新命名空间密钥，忘记所有旧数据并从头开始重建它。我只需要一个自动提醒，这样我就记得在需要时要这样做。
一些误报是可以接受的；假否定性不是。我很乐意将类似串行版本UID之类的简编码到我的测试案例中，并在更改基础类层次结构时进行更新。如果测试仅适用于DAG形的层次结构，则可以接受，但是绝对欢迎处理周期。
是否有某种方法可以通过使用typeTag机械来计算我想要的位？源类型声明的哪个方面兼容兼容性，以及如何使用EG typeTag来填写这些功能的表示？
我使用io.altoo.akka.serialization.kryo.kryoserializer to（de）序列化，请参见 https://github.com/altoo-ag/akka-kryo-serialization 。
I want to use kryo to serialize and deserialize a hierarchy of classes, like this:
case class Apple(bananas: Map[String, Banana], color: Option[String])
case class Banana(cherries: Seq[Cherry], countryOfOrigin: String)
case class Cherry(name: Option[String], age: Int, isTomato: Boolean)
Sometimes I want to add and remove fields somewhere in this hierarchy, e.g. to Cherry.
I would like to write a unit test which looks at the type hierarchy starting at Apple and concludes that data previously serialized with kryo will not deserialize properly—i.e. the deserialized object would not be == to the serialized object, if I could have both in memory simultaneously.
In that case, I can update a namespace key in my Redis cache, forget all the old data and rebuild it from scratch. I just need an automated reminder so that I'll remember to do this when I need to.
Some false positives are acceptable; false negatives are not. I'm happy to hardcode something like a serial version UID into my test case and update it whenever I change the underlying class hierarchy. It's acceptable if the test only works on DAG-shaped hierarchies, but handling cycles is definitely welcome.
Is there some way of computing the bit I want by using e.g. the TypeTag machinery to walk a description of the type hierarchy? Exactly which aspects of source type declaration does kryo compatibility depend on, and how do I plop out a representation of those features using e.g. TypeTag?
I use io.altoo.akka.serialization.kryo.KryoSerializer to (de)serialize, see https://github.com/altoo-ag/akka-kryo-serialization.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在该领域使用的一个技巧是检查序列化的旧序列化“重要”版本的数据（在此处证明是有用的Scalacheck及其生成器）。然后，您编写测试，从字面上检查新的序列化是否适当地进行了序列化。
您可能会在压力下遇到开发人员，以改变谁通过更改序列化数据（我发生在我身上）来改变避风式测试绿色。您可以通过在CI开始时检查序列化测试数据的校验和验证它们来解决此问题：更改这些校验和在审查中应该很明显，这是有问题的事情正在发生的。
我怀疑这种方法的回报率将比重新成熟的一部分Kryo类型系统的替代方案更好，并找出一种序列化该类型系统的表示方法，以与代码的未来版本进行比较。
One trick I've used in this area is to check in samples (ScalaCheck and its generators may prove useful here) of data serialized with "important" versions of the old serialization. Then you write tests that literally check that the new serialization properly deserializes.
You may run into a developer under pressure to get a change in who makes the deserialization test green by changing the serialized data (this happened to me). You can address that by checking in the checksums of the serialized test data and validating them at the start of CI: changing those checksums should be pretty apparent in review that something questionable is going on.
I suspect that this approach will have a somewhat better return-on-effort than the alternative of reimplementing a portion of kryo's type system and figuring out a way to serialize a representation of that type system for comparison against future versions of the code.