New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gomega not catching nils for pointers to structs #198
Comments
This is strange - the error appears to come out of Perhaps you can throw in a bit more context (e.g. the |
Closing this out - please let me know if you're still stuck @tnine |
Can we reopen? This issue still exists (gomega v1.10.5), I ran into it myself. I think I can explain it (after quite some head scratching...). Lines 101 to 110 in dbc6ecd
Therefore a nil pointer test with |
This is kind of consistent with the documentation. It just should be improved to document this caveat. It might also be useful to add a |
The root cause has been identified (onsi/gomega#198 (comment)), the right fix is to check for "err == nil" because the assertion alone is not enough in this particular scenario.
Re-opening as requested |
hey @pohly - |
I was using The function then uses Gomega to get nicer reports on failures compared to hand-written checks that return a normal error. |
ok got it - it's not possible for I think I see a few options:
I'd lean toward the second option as it will be the cleanest to reason about. |
I already have a PR pending which implements the second option. I think the current behavior of Manually catching the panic is not a good solution because that doesn't provide any meaningful report of what went wrong when the |
I'd happily take a PR for |
Would you be up for working on one? I think that's a fine solution for this usecase. If not I can work on something later this week. |
Durp and now I see your second comment: where you are proposing exactly this. Sorry @pohly - my bad for missing that. If you're up for a PR that would be great. Perhaps Or maybe even |
I don't think I'll have time for this this week, so feel free to go ahead.
Should it also catch a panic? Hmm, probably not. |
Ok, sounds good. I'll try to find some time to work on this. Thinking on it a bit more deeply - the root issue here is that |
hey @pohly - the latest commit (2f04e6e) implements It also improves the behavior of I'd love feedback on the commit before I cut a release. If you'd be up for running a |
I tried Thanks for adding this. |
The new Gomega version supports testing a function with no return value (onsi/gomega#198 (comment)). This makes it possible to simplify the metrics test.
hey @pohly - an issue has surfaced around the improved I'm working on a fix. Unfortunately, it will entail changing the contract for async callbacks that want to make assertions. In 1.14.0 you could pass The fix entails passing
I'm going to ship the fix in 1.15.0 but wanted to give you a heads up that it's coming. |
Thanks for the heads up. How will |
yes - it’s going to fail immediately and let you know that it needs to be changed.
… On Aug 2, 2021, at 6:13 AM, Patrick Ohly ***@***.***> wrote:
Thanks for the heads up.
How will Eventually(func() {...}) behave? Can you make that fail with an obvious error?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Just pushed out 1.15.0 - PTAL if you've got the time. |
Confirmed: "The function passed to Gomega's async assertions should either take no arguments and return values, or take a single Gomega interface that it can use to make assertions within the body of the function. When taking a Gomega interface the function can optionally return values or return nothing. The function you passed takes 0 arguments and returns 0 values."
Works. |
The new Gomega version 1.15 supports testing a function with no return value (onsi/gomega#198 (comment)). This makes it possible to simplify the metrics test.
From the messages above, it looks like this is working and can now be closed. |
Occasionally my tested code will return nil. This is expected, since it is an eventually consistent system. I have the following function within my test.
I receive the following stack trace with output.
As you can see
actual
is nil, andexpected
is not. I'm using revision c463cd2. Can you provide me with a suggestion on why this nil check is failing with both aNotTo(BeNil())
and aNotTo(PointTo(BeNil()))
? I'm at a loss to explain this behavior.Note that the line 263 referenced in the code is this line in the function.
Expect(actual.ID).Should(Equal(expected.ID), "Id should match")
The text was updated successfully, but these errors were encountered: