You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an expectation failed, the SQL request would error suggesting the type of the actual expectation. However, it is not detailed enough to show exactly which expectation failed. Consider the following simplified example.
--- FAIL: TestInsertValues (0.00s)
1_test.go:53: cannot insert values: call to ExecQuery 'INSERT INTO tbl (col) VALUES (?)' with args [{Name: Ordinal:1 Value:3}], was not expected, next expectation is: ExpectedCommit => expecting transaction Commit
1_test.go:57: unfulfilled expectation: there is a remaining expectation which was not matched: ExpectedCommit => expecting transaction Commit
FAIL
FAIL command-line-arguments 0.240s
FAIL
We know that the error happens because an ExpectCommit is not fulfilled, but it does not suggest which of the threeExpectCommits failed! This makes debugging test failure difficult.
I propose that
Every call to ExpectXXX() should record the stack trace, e.g. with the stack trace we would know it is the ExpectCommit() on line 41 causing the failure. And/or
Add a WithComment(string)/WithCommentf(string, ...interface{}) method to every ExpectedXXX type. The expectation failure would include the comment.
WithComment is needed to distinguish between different Expect invocations in a loop (where the stack trace would still be ambiguous) e.g.
fori, val:=rangevalues {
comment:=fmt.Sprintf("iteration #%d, value %s", i, val)
mock.ExpectBegin().WithComment(comment)
mock.ExpectExec("INSERT").WithComment(comment).WithArgs(val).WillReturnResult(sqlmock.NewResult(int64(i+1), 1))
mock.ExpectCommit().WithComment(comment)
}
The text was updated successfully, but these errors were encountered:
When an expectation failed, the SQL request would error suggesting the type of the actual expectation. However, it is not detailed enough to show exactly which expectation failed. Consider the following simplified example.
Example code
The code would fail like this:
We know that the error happens because an
ExpectCommit
is not fulfilled, but it does not suggest which of the threeExpectCommit
s failed! This makes debugging test failure difficult.I propose that
ExpectXXX()
should record the stack trace, e.g. with the stack trace we would know it is theExpectCommit()
on line 41 causing the failure. And/orWithComment(string)
/WithCommentf(string, ...interface{})
method to everyExpectedXXX
type. The expectation failure would include the comment.WithComment
is needed to distinguish between different Expect invocations in a loop (where the stack trace would still be ambiguous) e.g.The text was updated successfully, but these errors were encountered: