Fix json quotes escaping

[ferranpujolcamins]

I experienced problems with snapshots of string as json when the strings contain escaped quotes.

In the first commit I added an inline snapshot test that fails after taking the snapshot. The non-inline test passes.

In the second commit I made a dirty fix for the problem, but now the snapshot of the inline and non-inline tests are different. I don't know what is the proper way to fix this. Any idea? :)

[stephencelis]

Hi @ferranpujolcamins! Thanks for the PR. This is definitely a tricky gotcha. I think you can use raw string literals to avoid the original issue:

_assertInlineSnapshot(matching: value, as: .json, with: #"""
"""#)

But this isn't a great experience, so maybe inline snapshotting should detect what kind of literal it's in and escape there accordingly.

[ferranpujolcamins]

inline snapshotting should detect what kind of literal it's in and escape there accordingly.

I don't get what you mean. Can you elaborate a little bit?

[stephencelis]

inline snapshotting should detect what kind of literal it's in and escape there accordingly.

I don't get what you mean. Can you elaborate a little bit?

Ah, I mean if it sees a regular multiline literal:

_assertInlineSnapshot(matching: value, as: .json, with: """
""")

It records the following, escaped:

_assertInlineSnapshot(matching: value, as: .json, with: """
[
  "[\\"key\\": \\"value\\"]"
]
""")

(Note that it escapes each "\" as "\\".)

Meanwhile if it encounters a raw multiline literal:

_assertInlineSnapshot(matching: value, as: .json, with: #"""
"""#)

It records:

_assertInlineSnapshot(matching: value, as: .json, with: """
[
  "[\"key\": \"value\"]"
]
""")

(It left the \s alone.)

So it appears that the issue isn't so much about the .json strategy, but more about the fact that inline snapshotting doesn't play nicely with \s when using non-raw literals. Make sense?

[ferranpujolcamins]

Yes raw string literals fixed the issue. Thanks!

But this isn't a great experience, so maybe inline snapshotting should detect what kind of literal it's in and escape there accordingly.

It's not a big deal IMHO.

[stephencelis]

Glad that helped! We'd still rather not have folks stumbling on this gotcha, so I'll open another issue to track. Thanks!