Open dschveninger opened 8 months ago
hey @dschveninger - the Ginkgo stack trace always simply points to the location of the failure. In this case an Expect(..)...
is failing and Ginkgo is pointing to that failure.
It is up to the Gomega matcher to provide whatever information is necessary to adequately describe the failure to the user. In this case, since Gomega simply tells you that an error occurred. Since Go doesn't attach stack traces to errors by default there isn't anything Gomega can do out of the box to provide you with that information. (An error is just a value in Go - it doens't intrinsically contain any context about where it was generated outside of what you explicitly inject into it)
If, however, you use an error library that does provide stack traces then you have three options:
HaveOccurred
but emits the stack traceGomegaStringer
to generate custom output that includes the stack trace.Let's us try some of your suggestion. Thank you for the ideas. Once we find the best direction, we will update this issue and close it if you do not mind.
Expect(err).ShouldNot(HaveOccurred()) or Expect(err).ToNot(HaveOccurred())
Only give you the Expect stackTrace or the stackTrace of the DSL. We are looking for the stackTrace of the error
Example output of Expect(err).ShouldNot(HaveOccurred())
When we use github.com/pkg/error and Expect(err).NotTo(HaveOccurred(), "Error: %+v", err) we get a better stackTrace
Example output of Expect(err).NotTo(HaveOccurred(), "Error: %+v", err)
What is the proper way to get the Stack Trace of the error?
Code example
Output from code above run