Support non json

[JTeeuwissen]

Is your feature request related to a problem? Please describe.
The current snapshot functionality always uses json to store the snapshot data. When the string is not valid json, it is stored as a json string. This conversion and escaping makes it difficult to read larger chunks of e.g. serialized generated code.

Describe the solution you'd like
Id like a new api to snapshot strings (and potentially other objects) straight to a file, without any json conversion.

Solutions like Verify support this scenario, but i much prefer the snapper workflow.

[theramis]

Thanks for the suggestion!

Hmm this is something Snapper V1 used to support but it was much harder to maintain and I didn't see many users wanting that functionality.

Since then I've added Snapshots per class and Child snapshots as features which is something that really only works with json or some form of structured format.

These features would break if we wanted to store without json conversions.

I think there are two options for next steps

1. Snapper allows customer serialisers for json conversion. You could have a look at implementing one that makes your json conversions easier to read?
2. If there is enough interest by others I could investigate if Snapper could provide this but with limited functionality.

[JTeeuwissen]

The second option would match my use case. Child snapshots could be implemented using an extended file name. I could investigate an implementation, if this is something you feel like fits the library.

[torstenholva]

There is a problem with comparing datetimes in DevOps. When making the snapper json files locally (in another time zone) and then running the tests in DevOps, the time zone might change for the datetime and the test fails.

2020-09-10T00:00:00+03:00 changes to 2020-09-09T21:00:00+00:00

If the json file would be replaced with a snap file (for instance), would the datetime value be compared as a string?

[JTeeuwissen]

Probably yes,
But I think that is the wrong solution for your problem. Instead, could the test / sut be updated to have a Invariant timezone? Or use a date time without a time zone?

[torstenholva]

Yes, the latter was our solution to the problem. Will investigate if the first is an option in our context.
And thanks for a great tool, by the way! 👍