Skip to content
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

Open
ScottFreeCode opened this issue Feb 25, 2022 · 0 comments
Open

ANY times #45

ScottFreeCode opened this issue Feb 25, 2022 · 0 comments

Comments

@ScottFreeCode
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant