joseph-roitman
commented
3 years ago Hello, thanks for the suggestion. I guess that the library could also be useful for non-string objects.
We could safely add support for bytes in addition to str without changing the API or much downsides. pytest gives helpful diff messages for bytes, though they wont be as useful as for string data.
We could also add custom comparator logic, something like
@dataclass
class Person:
name: str
age: int
def compare(value: Person, expected_value: Person) -> None:
# This function should raise an exception if the values are different
assert value.name == expected_value.name and value.age == expected_value.age
def encode(obj: Person) -> bytes:
# This function should encode the object into bytes, preferably in a human-readable format for good readability.
return f'Person\n name: {obj.name}\n age: {obj.age}'.encode('utf-8')
def decode(data: bytes) -> Person:
# This function should reverse the ``encode`` function's operation.
return ...
snapshot.assert_match(obj, 'my_snapshot.txt', compare=compare, encode=encode, decode=decode)This would give the users the ability to use pytest-snapshot for almost any type of object.
There is one big downside to this solution. The user might encode data into the snapshot that he doesn't compare. For example, if the above compare function only compared the name and not the age. Anyone that looked at the snapshot file would probably assume that the age is also being tested, when in fact, it is not.
This is the reason that I would rather avoid supporting custom comparison functions.
So what do you think? Would supporting bytes be good enough? Or do you need custom comparator logic? I could add it, and put it at the bottom of the documentation with a warning of its downsides. Do you have any improvements to the API I specified above?
patbakdev
I have a scenario where I need to take and compare a snapshot of string and non string data (specifically EPUB and PDF). I use pytest-snapshot for the string data and have written additional functions to do the non-string comparisons, but I prefer not to have two snapshot solutions and would also like to be able to take advantage of the --snapshot-update ability.
I took a look at what @otosystems was doing with a custom-comparator in https://github.com/otosystems/pytest-snapshot/tree/custom-comparator, but it didn't fit my needs.
So I took a stab at creating an additional approach. You can find an initial proposal at https://github.com/patbakdev/pytest-snapshot/tree/custom-matcher. Basically, my plan is to allow for an optional func to be base to the assert_match methods. By default it would simply pass on to the existing string comparison function so its backwards compatible. I also wrote a simple filecmp function as a proof of concept/example and for use in tests. Presumably more matching functions could be provided in the future.
I don't think this is the best approach, but it was the least impactful. There is an unfortunate coupling between the plugin and the function needed for the update logic. A better approach might be to separate out the logic into a plug-able architecture with methods for snapshot update, comparison, etc., but that would require substantial changes to existing code and more time. Let me know if you are open to making some kind of change here and if so any thoughts you have on the approach/implementation.
Thanks