Binary Snapshot Support

[louy2]

I'd like to test a function rendering to an image, and I want to use snapshot testing. Currently I am using the Debug serializer but the resulting file is larger than my image and diff is useless. I'd really appreciate if I can generate image files and compare them visually, which means having the snapfiles open as image files.

I have thought about writing a serde serializer for image::DynamicImage, but AFAIK insta always adds the header so the resulting file cannot conform to an image format, which may prevent the file from being viewed as an image directly.

The metadata in the headers originally may be placed in EXIF tag UserComment for PNG and JPEG and in Comment Extension for GIF, although image doesn't seem to support metadata when encoding.

[mitsuhiko]

Even worse right now is the fact that insta is writing strings. So you won't be able to get anything binary through. I do agree though that there are cases where binary files are useful and screenshots is one of those reasons.

I think one way to approach this would be to emit .snap files with a new header that points to an out-of-band binary file. So something like this:

foo.snap

source: tests/test_image.rs
expression: "process_image()"
binary_snapshot: "foo.snap.png"

And then have the file in foo.snap.png. This has the added benefit that the original file extension can be kept (eg: png for a screenshot) and tools can better work with it.

[aminya]

By adding support for postcard, this issue can be fixed. Postcard serializes the data into a vector of numbers.

[mitsuhiko]

The issue is reviewing this. When working with binary snapshots (for instance pngs) one would want the snap files to be in a format that can be put into a viewer. So one idea was to make the snap files only contain the metadata and put the binary payload into an adjacent file.

[aminya]

Postcard supports deserialization from the stored bytes. So, the data can be restored and displayed using the Debug or Display trait.

[mitsuhiko]

Yes, but that does not address the problem that the file on the file system is not in a format that you can directly open with a viewer.

[adriangb]

+1 for this feature.

Even if the file isn't viewable in a viewer (in my case I'm snapshotting Postgres binary dumps) it is still useful to store it as a standalone file (in my case so that I can integration test by copying it via psql).

I think the snap could also hold some meta information about the binary file. Like size, maybe a hash? Size could be useful to see what's going on at a glance, hash I can't think of an immediate use case but can't hurt to have it.

[peterstuart]

@mitsuhiko I’m interested in working on this if you’d accept a PR implementing it. The approach you outline in #196 (comment) seems reasonable to me.

[mitsuhiko]

@peterstuart yeah, would be super happy to accept patches for this.

[nyurik]

How about actually showing the real images in the terminal, side by side, using viu?

P.S. Insta could also print two full paths to the files, or possibly even use open on request?

[zoechi]

Showing diffs like https://github.com/nicolashahn/diffimg
Flutter provides something like that with golden tests https://api.flutter.dev/flutter/flutter_test/GoldenFileComparator-class.html