-
Notifications
You must be signed in to change notification settings - Fork 2
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
ANY times #45
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Several mocks have a feature where one can set the
num_times
toNone
to assert at least once but no specific number of times matched (>0, >=1).I can't recall for certain but I think this predates the JSON APIs and
validation.ANY
.It would make more sense to use
ANY
instead ofNone
.Further, if
None
were no longer used for this purpose it would make it easier to avoid bugs conflating0
andNone
such as #44My suggestion around backwards compatibility, to avoid confusion (old Touchstone tests use
None
to mean any, but a newcomer would likely expect it to mean0
onceANY
can mean any), would be to make it an error to useNone
. This is backwards incompatible, but fails explicitly and clearly rather than behaving unexpectedly. In my experience most tests are using either the default (implicitly 1 time) or 0 (asserting something is not there), only a few special cases are using fuzziness such as "assert 3 calls to some URL matching this wildcard pattern" or "assert this was called, but assert it was called any number of times".While we're at it it may make sense to try to centralize more of the num times logic. As I recall we had an issue about correcting a
0
vsNone
bug re. equals vs.is
, it had to be corrected separately in each mock.The text was updated successfully, but these errors were encountered: