-
Notifications
You must be signed in to change notification settings - Fork 40
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
Easier usage with floats #913
Comments
You can use a matcher based on type rather than attribute name. Regardless, this has come up before. Open to ideas/contributions. |
Interesting, I'm not sure i understand the matcher system based on the docs, I came away with the impression it would simply be asserting an attribute had a specific type. I was hoping I could do something like that but failed and was looking at custom serializers. Ideally i could just drop in the pytest.approx function, i would be happy to make a docs PR with an example of how to do it if you can show me how! |
A matcher is a function which takes two arguments:
it then returns the "new" value. It's essentially just a replacement function (maybe "matcher" was a bad name in hindsight). We have 2 built-in matchers which provide some syntactic sugar:
In Syrupy v5, multiple matchers can be composed using "compose_matchers". In your case: def test_round_float(snapshot):
assert (2.0 / 3.0) == snapshot(
matcher=path_type(
types=(float,), replacer=lambda data, _: round(data, 5)
)
) which produces a snapshot like so:
To use something like pytest.approx is a bit tricky because we need to serialize some value. In theory you could override the syrupy/src/syrupy/extensions/base.py Line 412 in bbc5f12
Let me know if that helps. |
Thanks for the in depth reply! I'll see what I can come up with tomorrow |
**Is your feature request related to a problem? Please describe **
We can't use syrupy when we are snapshotting objects with floats in them, due to precision issues.
Describe the solution you'd like
A way to set up a level of precision to match floats, ideally globally for all tests via a config option.
Describe alternatives you've considered
Using custom matchers on an individual attribute basis but thats a giant pain.
Additional context
The text was updated successfully, but these errors were encountered: