Perfect roundtrips on plaintext snapshots

[nedtwigg]

I think it's important for plaintext snapshots to have perfect roundtrips. That means that it's okay if the encoded text isn't exactly the same as the original text, but when decoded it should be exactly the same again, including newlines. I can see a good argument for removing all \r from snapshots though...

Dumb example: if you change every character into open paren unicode number hex close parent so that A becomes (41), that encoding is bad, but lossless. You get back exactly what you put in.

By picking rare characters for the brackets and escape characters, you get an encoding which is almost always just the text on its own, but in the rare case that you need to escape some characters to encode, you can still perfectly decode.

I dumped some example code which does encoding of that type into #126, feel free to use it if you'd like.

[jackmatt2]

I think I'm seeing the advantage of this now. So is the case of this library - it's not clear whether the snapshot was for \n\n\n or \n.\n.\n because encoding is conditional based on input.

ATM only three consecutive lines are "special". The reason I used \n. was that you still get a similar look to the snapshot. Perhaps "." should be replaced with a non-printable character though - something weird to avoid conflicts and escape that character as necessary.

[nedtwigg]

Non-printable characters are hard to debug. If it was me, I would go with ⟨⟩ for brackets and ° for the escape character. With PerCharacterEscape.specifiedEscape("°.⟨<⟩>") the encoded text can be exactly the same as the original text but with the following substitutions:

• ° -> °.
• ⟨ -> °<
• ⟩ -> °>

So when you're parsing a snapshot file, your parser can be really simple and know for sure that a ⟨ must be part of the super-structure and not the content, but the content inside can still have any character.

A good testcase is this: can you use your snapshot testing library to take snapshots of it own snapshots? The answer should be yes!