0

While working on unit tests for a project which generates html using the Razor engine, I discovered a really weird scenario.

In order to get the unit test to be correct, I hard-coded the model, called the function, and saved the generated html code. Our business users viewed the generated html and gave the seal of approval, and our designers examined the html code and said everything looks good.

I now had an html file which I could use to compare against in the unit test to ensure that any changes to the code would not produce a different html file given the exact same model data.

On my local development machine, the unit test passes when comparing the byte array (File.ReadAllBytes(path)). However, on our build agent the unit test fails due to extra ASCII 13 bytes, here is a snippet of a section of the byte arrays:

  Build Agent: 111-100-121-62-13-10-32-32-32
Local Machine: 111-100-121-62-10-32-32-32

I'm not sure what is going on here or how to resolve this. Is this normal? How would I rewrite the test to fixes this?

Additional Information:

  • The build agent is running Windows Server 2016, Visual Studio 2017 15.7.6
  • My local development box is running Windows 10 Enterprise 10.0.14393, Visual Studio 2017 15.8.1
myermian
  • 31,823
  • 24
  • 123
  • 215
  • 1
    Looks like your build agent is using a carriage return line feed as it's endline, while your local machine is using just a line feed. Are you using `Environment.NewLine`? Is your dev box linux and your build agent windows? – Jonathon Chase Aug 21 '18 at 18:05
  • @JonathonChase: Yes, I looked up ASCII 13 and it's the CR, not sure why my local machine didn't generate the same byte data. Is there a better way to compare the html files than byte array? – myermian Aug 21 '18 at 18:11
  • Are you using git for version control? There's a chance you're using the *nix line endings setting on your development box, while the build agent is using the setting to checkout files with windows line endings/commit with *nix, which would cause the file you are comparing to to checkout with the carriage return. If this is the case, you can set the git attributes to use the *nix line end settings, [as shown here](https://stackoverflow.com/questions/10418975/how-to-change-line-ending-settings) – Jonathon Chase Aug 21 '18 at 18:17
  • Preserver LF, CR: https://stackoverflow.com/a/23014006/3142139 – M.Hassan Aug 21 '18 at 18:18
  • @JonathonChase: Yes, I am using VSTS Git, private build agents, dotnet tasks, yaml build definitions. Not sure about the *nix line ending setting on my local dev, I just used whatever VS 2017 supports out of the box. – myermian Aug 21 '18 at 18:21
  • You can check the settings on each box with `git config --get core.autocrlf`. If the build agent is `true` and your dev box is `input` or `false` I would add the .gitattribute to make them consistent. – Jonathon Chase Aug 21 '18 at 18:25

1 Answers1

0

"different html file given the exact same model data": There are infinitely many different HTML files that are semantically equivalent when parsed and even more when rendered.

To get over your hurdle though—if you don't need to consider newlines in <pre> and related elements—you could just

//Note: Ignoring newlines because they are believed to be insignificant. No <pre> etc expected.
// This allows newlines to vary across systems and across time.
Func<String, List<String>> splitByLineAndRemoveEmpty = 
    input => Regex.Split(input, @"\r|\n").Where(line => !String.IsNullOrEmpty(line)).ToList();

CollectionAssert.AreEqual(
    splitByLineAndRemoveEmpty(expected), 
    splitByLineAndRemoveEmpty(File.ReadAllText(path)));

That could kick the can far enough down the testing road that it won't bother anyone again for awhile.

Tom Blodget
  • 20,260
  • 3
  • 39
  • 72