Add line normalisation to reporters

[JakeGinnivan]

Currently the line ending normalisation only affects the approver side of things, when the reporters report failures they do not perform the normalisation which obscures the real error.

[jamesrcounts]

As long as we can opt out of normalization in the files written to disk.

I've had scenarios where downstream systems would break if the line endings were not exactly as expected, and so normalizing them would mask errors in that scenario.

I think this is less common than cases where it does not matter, so the default can be normalization, but there needs to be a way to opt out.

[JakeGinnivan]

The files written to disk are not normalised, it is only a validation/reporting concern. It also can be opted out via an attribute. Git normalises files by default, and different environments respect gitattributes, others do not. So we really need the normalisation feature.

This issue is just for the reporters, at the moment the approvers normalise, but then the reporter shows the diff which is line endings. My issue was that my DateScrubber was not matching the build servers date format, and the fact the reporter was showing the line ending diffs was hiding the real error.

[JakeGinnivan]

It would be awesome if ApprovalTests setup readthedocs.org and started working on a central docs repo, the info about line ending normalisation I would be happy to write up in a doc if readthedocs was setup

[jamesrcounts]

So what do you have in mind for the reporting? Most reporters expect files to exist on the disk. Normalizing the received file is easy enough since it is temporary. However, to normalize the approved side there has to be something on the disk. We could make the reporting easy enough by copying the approved file to a temp location and normalizing it, then using that temp file as the right side of the compare. But if we do that then how do you approve anything, since your merges are now going into a temp file?

To me the feature works just fine if you normalize the files written to disk (leaving an opt-out for a test here or there that requires exactness), but I'm not sure what to do if we don't take that step. We don't control the diff utility implementations, we only control whether or not we invoke them and which files we provide to them.

[JakeGinnivan]

It is just the build server and non-diff reporters. The files written should not be normalised, only when reporting failures should it normalise.

Sent from my Windows Phone

---

From: Jim Countsmailto:[email protected] Sent: ‎8/‎09/‎2015 9:54 PM To: approvals/ApprovalTests.Netmailto:[email protected] Cc: Jake Ginnivanmailto:[email protected] Subject: Re: [ApprovalTests.Net] Add line normalisation to reporters (#134)

So what do you have in mind for the reporting? Most reporters expect files to exist on the disk. Normalizing the received file is easy enough since it is temporary. However, to normalize the approved side there has to be something on the disk. We could make the reporting easy enough by copying the approved file to a temp location and normalizing it, then using that temp file as the right side of the compare. But if we do that then how do you approve anything, since your merges are now going into a temp file?

To me the feature works just fine if you normalize the files written to disk (leaving an opt-out for a test here or there that requires exactness), but I'm not sure what to do if we don't take that step. We don't control the diff utility implementations, we only control whether or not we invoke them and which files we provide to them.

— Reply to this email directly or view it on GitHubhttps://github.com/approvals/ApprovalTests.Net/issues/134#issuecomment-138567001.

[JakeGinnivan]

In particular I need AssertReporter to normalise

[stocksr]

I think this is the same issue but I got this failure message on my build server - when the tests passed locally

Expected string length 1679 but was 1522. Strings differ at index 116.
Expected: "...s greater than maxResponse="0"\n at SurveySchema.Serializ..."
But was: "...s greater than maxResponse="0"\r\n at SurveySchema.Seriali..."
---------------------------------------------^ 

and wasted half the morning investigating line endings, The important difference was actually that the tests where running on a release build and a method further down the callstack had been inlined.

[ForNeVeR]

In my case, the server was reporting line endings, but the real issue was a single float formatted in a different way somewhere in a middle of 12 Kb JSON. This issue is a pain, let's fix it!

[SimonCropp]

given this was 5 years i assume u have on. so will close. please let us know if u still need this

[jnyrup]

@SimonCropp I am still interested in having this issue solved. Right now the failure message in our pipeline points at the first difference in newline endings, instead of the first real difference. https://ci.appveyor.com/project/dennisdoomen/fluentassertions/builds/31620746

[SimonCropp]

@jnyrup thanks for getting back to me. i will look into this

[wischi-chr]

Is there a workaround for that?

Every time the approval fails on the build server (but not locally) it's pretty hard to identity the real issue, because the output doesn't help at all:

  Error Message:
   Assert.Equal() Failure
           ↓ (pos 1)
Expected: {\r\n  "openapi": "3.0.1",\r\n  "info": {\r\n   ···
Actual:   {\n  "openapi": "3.0.1",\n  "info": {\n    "t···
           ↑ (pos 1)
  Stack Trace:

Update: I'm on version 5.4.5, I think that's the most recent one on nuget.

[SimonCropp]

This project is not being actively maintained. Instead consider using Verify. See Migrating from ApprovalTests for more information.