我正在编写一个接受数据表的代码生成器,并使用它生成来自数据表中的锅炉板c#代码。
我正在创建一个我创建的c#代码文件并将其与我的代码生成器生成的字符串进行比较。
我将代码文件从磁盘读取到一个字符串,并将其与生成的字符串进行比较,并将字符串作为参数传递给Assert.AreEqual - 这会失败。如果我将生成的字符串写入文本文件并进行比较,则文本显示相同 - 但文件大小略有不同,并且使用文件比较实用程序,文件末尾似乎有一个额外的上部ascii类型字符这是通过我的代码生成器创建的。
关于"上部ascii"如果我使用十六进制编辑器比较文件,则在使用Visual Studio创建的文件的开头和结尾处有一些额外的十六进制值,这些值在我的应用程序创建的文件中不存在。开头的那些十六进制值是:" EF BB BF"最后的值是:" 0D 0A"。
可能解释的另一条线索:当我将生成的文件添加到Visual Studio中的项目时,我会看到以下消息:"以下文件中的行结尾不一致。您想要对行结尾进行标准化吗?"
单元测试的内容:
[TestMethod]
public void TestGenerateBDO()
{
const string originalCodePath = @"c:\temp\UnitTestGenerator\BugSource.cs";
BusinessDomainGenerator generator =
new BusinessDomainGenerator(new System.Data.DataTable(), "BugsBDO", "Bug");
// this adds the body of the text file
AddTestGenerateBDOCodeLines(generator);
// I've tried using the 2nd parameter of ReadAllText to pass
// different encodings - no difference
string originalCode = System.IO.File.ReadAllText(originalCodePath);
string formattedCode = generator.GetGeneratedCode();
Assert.AreEqual(originalCode, formattedCode);
}
答案 0 :(得分:2)
在这些情况下我通常会做的事情:
请注意0D 0A
是“回车和换行”(\r\n
),即新行。这可能是你的问题,因为最后一个\r\n
的字符串与没有字符串的字符串不同。如果是这种情况,您可以通过首先在两个字符串上调用Trim()
来处理此问题。
EF BB BF
是byte order mark并且出现在文件的开头,表示文件是以UTF-8编码的。在阅读文件时,.Net框架将使用此信息来决定使用哪种编码,但它们不会成为字符串的一部分,因此不会导致测试失败。