-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Message argument checking is inconsistent between functions #316
Comments
Hey @prashantv,
That's how it is supposed to work.
Sorry, I'm having a hard time understanding what you mean by this. Can you elaborate a bit more? |
Yes, I understand that, but my issue is more that when the user makes a mistake and passes multiple errors, the handling is different based on whether it's If you pass two errors by accident to This is an inconsistency, and I personally think both methods should ensure that when you do: assert.Error(t, err, someArg) The method should always ensure that |
@prashantv sorry it took long to reply, I have been very busy. Would you like to issue a PR changing every assertion to fail when the first element of |
@ernesto-jimenez Sure, I can take that on. |
awesome, thanks! |
This seems related to #119. |
Hey guys, package example
import (
"errors"
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestRequireError(t *testing.T) {
err := errors.New("custom error 1")
_ = err
// require.Error(t, nil, err, "err should be present") // panics interface conversion err
// require.Error(t, nil, nil, "err should be present") // panics interface conversion err
require.Error(t, nil, "context: %s", "err should be present")
}
func TestRequireNoError(t *testing.T) {
err := errors.New("custom error 2")
_ = err
// require.NoError(t, err, nil, "err should NOT be present") // panics interface conversion err
// require.NoError(t, err, err, "err should NOT be present") // panics interface conversion err
require.NoError(t, err, "context: %s", "err should NOT be present")
}
func TestAssertError(t *testing.T) {
err := errors.New("custom error 3")
_ = err
// assert.Error(t, nil, err, "err should be present") // panics interface conversion err
// assert.Error(t, nil, nil, "err should be present") // panics interface conversion err
assert.Error(t, nil, "context: %s", "err should be present")
} To me, the behavior is consistent among them. If not, can you bring me in the right direction so I can file a PR to fix that mismatched behavior? |
Is an issue still relevant? cc @arjunmahishi |
@myusko I'm not sure is this is still relevant. I think most of the functions are handling this in a pretty consistent way. Can you help in verifying that? We need to make sure that all the assertions using the Looks like none of the http assertions are using the msgAndArgs at all. I'll file a separate issue for that. |
Yup, I can help with that, but seems like you already even created a PR, sonic's speed, hehe. |
It seems like this issue has mostly been worked around. I like this suggestion would entirely fix the problem but would need v2. |
I recently ran into an issue where we accidentally passed two different errors to
require.NoError
:It was incorrectly testing the previous
err
instead of the output of callingTestFunc()
. I've noticed thattestify
is inconsistent between whether it checks the arguments before checking if the condition failed, or whether it's only checked if the condition fails.I've written a couple of simple tests to show the difference:
In both cases, we're passing two errors -- the second is what we actually want to compare. However, the first error we pass would pass the assertion, while the second is the one we intended, and would cause the assertion to fail.
The output of
TestRequireErr
:The output of
TestRequireNoErr
:I think both assertions should be consistent -- and ideally, they both ensure that the
msg
is actually a string regardless of the condition, since the compiler can't enforce this.The text was updated successfully, but these errors were encountered: