如何进行向后和向前兼容性的单元测试？
我正在开发一个使用 Java 序列化的插件 API。这个想法类似于SmallTalk的系统镜像。我想知道如何最好地自动化测试我所做的更改是否会破坏反序列化，因为某些更改似乎是无害的，例如向已实现的接口添加方法（只要不调用该方法，否则会导致一个AbstractMethodException）。
是的，这更多的是实验性的峰值而不是生产代码，因此请不要建议不使用序列化。
I am working on developing an Plug-In API that uses Java serialization. The idea is similar to SmallTalk's system images. I was wondering how would to best to automate testing for whether changes I am making will break deserialization since some changes seem to be innocuous like adding a method to an interface that is implemented (as long as that is not called, otherwise it will result in a AbstractMethodException).
Yes, this is more for an experimental spike rather than production code so please do not suggest not using serialisation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为了数据的向后兼容性，以二进制形式保留大量旧消息，并查看是否仍然可以使用新代码反序列化它们。
为了实现代码的向后兼容性，您需要某种方法来构建旧代码（例如每个版本一个版本）并针对从最新版本的代码创建的数据进行测试。这是一个稍微更具挑战性的问题 - 您可能希望在每个适当的版本上构建一个小型测试 jar，并同时将该放入源代码管理中，以避免一次又一次地构建相同的代码。然后，您的测试将针对新代码的输出尝试所有不同的 jar 文件。
老实说，对于一个实验性的峰值来说，这一切听起来像是相当大量的工作。对于实际工作，我当然只使用 协议缓冲区 :)
For backward compatibility of data, keep a lot of old messages in binary form, and see if you can still deserialize them with the new code.
For backward compatibility of code, you'll need some way of building your old code (e.g. one version per release) and testing that against data created from the newest version of the code. This is a slightly more challenging problem - you may want to build a small test jar on each appropriate release, and put that into source control at the same time to avoid having to build the same code again and again. Your tests would then try all the different jar files against the output of the new code.
To be honest, this all sounds like quite a lot of work for an experimental spike. For real work I'd just use protocol buffers of course :)