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
Currently, the extra matchers given to Should(matcher, extraMatcher1, ...) are silently ignored and the assertion passes successfully (see the example below). This happens when a user forget (...me, actually) to wrap the matchers with SatisfyAll() or other composition matchers. The problem is that this gives the wrong impression to the user that the SUT is working correctly.
It would be great if Gomega can detect this kind of incorrect usage and fail the test, notifying the user that the test should be fixed.
The issue is that the optionalDescription ...interface{} is not validated unless the assertion fails. It seems reasonable that the length and type could always be validated so that usability issues such as the one outlined above could be improved.
Can work on a PR; should having a Gomega matcher in the optionalDescription cause a panic or a fail? I would expect the latter, as this is what we do when vetting the actual values. However, optionalDescription is part of the static test, so maybe a panic would be better?
thediveo
added a commit
to thediveo/gomega
that referenced
this issue
Jul 25, 2022
Currently, the extra matchers given to
Should(matcher, extraMatcher1, ...)
are silently ignored and the assertion passes successfully (see the example below). This happens when a user forget (...me, actually) to wrap the matchers with SatisfyAll() or other composition matchers. The problem is that this gives the wrong impression to the user that the SUT is working correctly.It would be great if Gomega can detect this kind of incorrect usage and fail the test, notifying the user that the test should be fixed.
Example: (Gomega 1.19.0)
The text was updated successfully, but these errors were encountered: