英文:
Can Gomega equal with ginkgo print full strings?
问题
单元测试的示例错误打印:
期望值
<string>: "...up - Finish..."
实际值 |
<string>: "...up - Vault ..."
有没有办法增加打印的限制,这样实在太不实用了...
至少可以增加到100个字符吗...
编辑:
我可能没有提供足够的信息:
Vault ...
Finish...
不仅是字符串中不同的部分,如果发生错误,没有更多的上下文很难阅读。应该有一种方法允许完整的比较打印输出,类似于NodeJS Chai中的方式。
英文:
Example error print of a unit test:
Expected
<string>: "...up - Finish..."
to equal |
<string>: "...up - Vault ..."
Is there a way to increase the print limit this is just not practical at all...
Like at least to something like 100 signs...
Edit:
I might not have given enough information:
Vault ...
Finish...
Are not the only parts that are different in the string and it is very hard to read without more context if an error occurs. There should be a way to allow full comparison prints no? Similar as to how it is in NodeJS Chai.
答案1
得分: 2
我不相信在不修改底层的Ginkgo代码的情况下能实现这一点,至少根据我的阅读和实验来看是这样的。Ginkgo使用自己的报告框架,你可以利用它来自定义输出...但有一定的限制。
查看原始报告输出的一种方法是使用ginkgo
的--json-report <PATH>
标志将其转储为json:
$ ginkgo --json-report=spec-out.json
我创建了一个简单的规范,比较了两个非常长的字符串(只是重复的英文字母表,用空格分隔,多次重复),只有一个字母块被替换为"foobar",与正常输出相关的报告内容被限制为:
"Failure": {
"Message": "Expected\n <string>: \"...wxyz abcdef...\"\nto equal |\n <string>: \"...wxyz foobar...\""
然后,我改变了被比较的字符串,使得差异延伸得更长,但消息仍然相同,仍然截断到不匹配的初始点。
你可以通过Ginkgo本身访问底层的报告框架,例如:
ReportAfterEach(func(report SpecReport) {
fmt.Fprintf(os.Stderr, "SPEC REPORT: %s | %s\nFAILURE MESSAGE: %s\n", report.State, report.FullText(), report.FailureMessage())
})
这也返回了消息中的截断字符串,这表明我认为没有容易访问的机制来获取更长的字符串输出 - 因为这可能是在较低级别生成的(我认为是在Equal()
匹配器的代码中,但我还没有查看):
SPEC REPORT: failed | Utils Compares really long strings
FAILURE MESSAGE: Expected
<string>: "...wxyz abcdef..."
to equal |
<string>: "...wxyz foobar..."
有关详细信息,请参阅ginkgo报告文档和ginkgo godoc的相关部分。
英文:
I do not believe this is possible without modifying the underlying Ginkgo code, at least from my reading and experimentation. Ginkgo uses its own reporting framework, and you can leverage that to customize the output...within limits.
One way to see the raw report output is to dump it as json with the --json-report <PATH>
flag for ginkgo
:
$ ginkgo --json-report=spec-out.json
I created a simple spec that compared two really long strings (just the English alphabet repeated, separated by spaces, a bunch of times), differing only in the replacement of a single alphabet block with "foobar", and the contents of the report relevant to what you'd see in the normal output were limited to:
"Failure": {
"Message": "Expected\n \u003cstring\u003e: \"...wxyz abcdef...\"\nto equal |\n \u003cstring\u003e: \"...wxyz foobar...\"",
Then I changed the compared string so that it the diff extended for a much longer stretch, and the message was identical - still truncated to the initial point of mismatch.
You can access the underlying reporting framework through Ginkgo itself, for example:
ReportAfterEach(func(report SpecReport) {
fmt.Fprintf(os.Stderr, "SPEC REPORT: %s | %s\nFAILURE MESSAGE: %s\n", report.State, report.FullText(), report.FailureMessage())
})
This also returned the truncated strings in the message, which would indicate to me that there is no easily accessible mechanism for getting a longer string to output - since this is presumably generated at a lower level (I'm thinking in the code for the Equal()
matcher, but I haven't looked yet):
SPEC REPORT: failed | Utils Compares really long strings
FAILURE MESSAGE: Expected
<string>: "...wxyz abcdef..."
to equal |
<string>: "...wxyz foobar..."
For reference see the ginkgo reporting docs and relevant portion of the ginkgo godoc.
答案2
得分: 2
请看这个链接:https://github.com/onsi/ginkgo/issues/1166,onsi已经回答了。请查看format
包。
英文:
https://github.com/onsi/ginkgo/issues/1166 Have a look at this, onsi answered. Look at the format
package.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论