单元测试的错误打印示例:
Expected
<string>: "...up - Finish..."
to equal |
<string>: "...up - Vault ..."
有没有办法增加打印限制,这根本不切实际...... 至少有 100 个迹象......
编辑: 我可能没有提供足够的信息:
Vault ...
Finish...
这并不是字符串中唯一不同的部分,如果发生错误,如果没有更多上下文,则很难阅读。应该有一种方法可以允许完整的比较打印不是吗?与 NodeJS Chai 中的类似。
https://github.com/onsi/ginkgo/issues/1166看看这个,onsi回答。看看
format
包装。
我认为如果不修改底层的 Ginkgo 代码这是不可能的,至少从我的阅读和实验来看是这样。 Ginkgo 使用自己的报告框架,您可以利用它来自定义输出......在限制范围内。
查看原始报告输出的一种方法是将其转储为 json,并使用
--json-report <PATH>
标志表示 ginkgo
:
$ ginkgo --json-report=spec-out.json
我创建了一个简单的规范,比较两个really长字符串(只是重复的英文字母,用空格分隔,多次),不同之处仅在于用“foobar”替换单个字母块,以及与您在正常输出中看到的内容相关的报告仅限于:
"Failure": {
"Message": "Expected\n \u003cstring\u003e: \"...wxyz abcdef...\"\nto equal |\n \u003cstring\u003e: \"...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 的相关部分。
至少对我来说,在断言之前添加临时打印语句是最简单的方法:
fmt.Printf("=============================>>> Actual: %+v\n", actualResult)
如果有很多输出,等号的“大”标记有助于找到输出。
下次我开始一个项目时,我不会使用Ginkgo/Gomega。