Allow preprocessing images before comparison

[sbekrin]

This PR adds a hook function beforeComparison with signature (received, baseline) => ({ received, baseline }), which allows to modify both received and baseline images before passing it to pixelmatch for comparison. This is handy for cropping, resizing or doing any other manipulations for handling edge-cases.

[anescobar1991]

@sergeybekrin I spent some time discussing this with my team and we are not going to be merging this feature:

Being able to modify the baseline image is a no-go as it works against the principles of how Jest snapshots are meant to behave. If the received image does not match the baseline image then the test should fail and the user then has the choice of either accepting the new image as the new baseline, or fixing the root cause of whatever caused the image to not match.

I am not sure what value being able to modify the baseline image gives you as it would mean that either a) your original baseline would never actually be used or that b) you would be constantly modifying your test after the original implementation in order to account for an unpredictable image.

The base assumption under which jest-image-snapshot operates is that the received image is fully replicable. If modifications to the image are required in order to satisfy that assumption (like to mock out a region of the image that can vary or is beyond the user's control) then those need to be done prior to passing it to toMatchImageSnapshot() and that does not require a beforeComparison option to be implemented.

For your use case that is what I suggest you do is make sure that your original image is replicable before it gets passed to toMatchImageSnapshot() so that your tests can work as expected without modification after the fact. Based on what you previously mentioned this might involve changing your approach. Could you black out the areas you want to ignore instead of cropping them out? Then I would assume the image size would remain the same and the images would be fully deterministic no?

[sbekrin]

@anescobar1991 I see your point. We'll try another approach with fixed size safe area then, thanks!