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
Several mocks have a feature where one can set the num_times to None 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 of None.
Further, if None were no longer used for this purpose it would make it easier to avoid bugs conflating 0 and None such as #44
My suggestion around backwards compatibility, to avoid confusion (old Touchstone tests use None to mean any, but a newcomer would likely expect it to mean 0 once ANY can mean any), would be to make it an error to use None. 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 vs None bug re. equals vs. is, it had to be corrected separately in each mock.
The text was updated successfully, but these errors were encountered:
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: