自定义期望中传入参数的格式
我正在使用 jmock 模拟 OutputStream 并对写入其中的数据设置期望。
所以我期望看起来像这样的
oneOf(stream).write(byteArrayMatching("Some string"));
(byteArrayMatching) 是一个自定义匹配器的工厂。
这一切都工作正常，除了当测试失败时，因为被测类写入了不正确的数据，我得到一个看起来像这样的错误：
java.lang.AssertionError: unexpected invocation: stream.write([<60>, <63>, ...])
通过查看字节序列来识别数据到底有什么问题是相当困难的（我还没有还没来得及记住 ASCII）。 这几乎迫使我在调试器中运行测试以找出问题所在。
我的问题是：有没有一种方法可以以某种方式向模拟对象或 Mockery 对象注册某种格式化程序，从而可以很好地打印参数值？ 很明显，jmock 已经做了一些漂亮的打印，因为上面不是 byte[].toString() 的输出，但我在 API 文档中找不到任何建议的方法自定义这个漂亮的打印逻辑
I'm using jmock to mock out an OutputStream and set expectations on the data that gets written to it.
So I have an expectation that looks something like this
oneOf(stream).write(byteArrayMatching("Some string"));
(byteArrayMatching) is a factory for a custom matcher.
This all works fine, except when the test fails because the class under test writes incorrect data, I get an error looking something like this:
java.lang.AssertionError: unexpected invocation: stream.write([<60>, <63>, ...])
It's pretty hard to identify what exactly is wrong with the data by looking at the sequence of bytes (I haven't gotten around to memorizing ASCII yet). This pretty much forces me to run the test in a debugger to figure out what's wrong.
My question is: is there a way to somehow register a formatter of sorts with the mock object or the Mockery object which can pretty print a parameter value? It's clear that jmock is already doing some pretty-printing, since the above is not the output of byte[].toString(), but I can't find anything in the API docs that suggests a way to customize this pretty-printing logic
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当前（2.5.1）jMock 库中无法执行此操作。 我建议您记录增强功能到jMock。
There is no way to currently do this in the current (2.5.1) jMock library. I would suggest you log an enhancement to jMock.
可爱的答案是，模拟对于您定义的类型更有意义，该类型具有一些域结构，而不是外部 API。
下一个答案是查看 Hamcrest 的新版本，其中包括对报告不匹配的支持。
除非涉及序列，否则下一个答案是，在这种情况下，最好使用内存中的字节流并随后断言字符串。
请也提出问题:)
The cute answer is that mocking makes more sense against a type that you've defined, that has some domain structure to it, rather than external API.
The next answer is to look at the new version of Hamcrest which includes support for reporting a mismatch.
The next answer, unless there's sequence involved, is that in this case it might be better to use an in-memory byte stream and assert the string afterwards.
And file an issue too, please :)