如何在 NUnit 中编写测试方法来测试 savefile 方法？
我编写了一个 savefile 方法来将对象保存到 xml。 但我不确定如何在 NUnit 中测试该方法。 我是否需要手动创建示例文件并比较文件之间的字符串？ 有没有更好的方法来测试该方法？
感谢您的回答。
I wrote a savefile method to save an object to xml. But I am not sure how to test the method in NUnit. Do I need create a sample file manually and compare the string between the files? Are there any better ways to test the method?
Thanks for your answer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
呃，正在验证 XML 输出。 欢迎来到地狱:)
对我有用的一种方法是在内存中生成一个
XmlDocument对象。 然后运行 SaveFile 方法，并将其加载到另一个XmlDocument中。 递归地遍历两个 XmlDocument，比较所有元素和属性。不幸的是，用 C# 对象编写 xml 又大又笨重。 我建议一次测试几个小节。 也许您的保存文件具有
Ugh, validating XML output. Welcome to hell :)
A method that has worked for me was to generate an
XmlDocumentobject in memory. Then run your SaveFile method, and load it into anotherXmlDocument. Walk both XmlDocuments recursively, comparing all elements and attributes.Unfortunately, writing xml with C# objects is big and bulky. I'd recommend testing subsections at a time. Maybe your save file has a
<FileList>sub element, a<Cups>sub element, and<Rifles>sub element. In that case, write a series of tests to ensure that each sub section is done correctly, instead of the overall output.如果你展示代码会更容易。
我的解决方法是添加一个抽象层。
不要让 Save 方法直接处理 XmlWriter。 相反，创建包装器，每个包装器都能够将数据的小逻辑块保存到 xml，并测试它们。
对于每个包装器都有一个类似的方法
，让 Save 仅从包装器收集数据。 换句话说，正确保存数据将是包装器的责任，但每个包装器只负责其中的一小部分。
在那里您可以通过比较字符串来测试它（将 StringWriter 放入您传递到 Persist 方法的 XmlWriter 中）
It would be easier if you showed the code.
My way around this, is to add a layer of abstraction.
Do not have your Save method deal directly with XmlWriter. Instead create wrappers that will each be able to save small logical chunk of your data to xml, and test those.
for each Wrapper have a method like
and let Save just collect the data from the wrappers. In other words, it would be Wrappers' responsibility to save the data properly, but each will be responsible just for the small chunk of it.
There you can test it by comparing strings (put StringWriter into XmlWriter you pass into Persist method)
选项
Options
这就是我所做的——它对我有用，但可能不符合您的规格。
在拆解过程中，我确保删除了我可能作为套件的一部分创建的所有文件。 所以是的，确保该文件是一个临时文件，仅用于测试
在测试方法中，如果该文件存在，我会删除该文件（不应该，因为拆卸已经处理了它），然后将文件输出到 XML，然后断言文件已存在。 然后，我将文件重新加载到对象图或 xml DOM 中，并根据需要通过尽可能多的断言查询状态。
如果您可以避免写入文件，并且您的设计允许您写入通用文本写入器或 xml 写入器，那么您可以绕过文件保存并用字符串写入器替换调用，然后只查询字符串。 更干净，但它没有测试实际的文件持久性是否有效。
Here's what I do -- it works for me but it might not be to your specifications.
In the teardown I make sure I delete any files I might have created as part of the suite. So yes, make sure the file is a scratch file just for testing
In the test method I delete the file if it exists (it shouldn't as the teardown has already taken care of it), then output the file to XML then assert the file exists. I then reload the file either into an object graph or into the xml DOM and query the state through as many assertions as you need.
If you can get away with writing to files and your design allows you to write to a generic text writer or xml writer then you could bypass the file save and replace the calls with a string writer instead and just query a string. Much cleaner but it doesn't test that the actual file persistence is working or not.
设计您的类，以便拥有 SaveFile( string fileName ) 和 SaveFile( XmlWriter writer)。 SaveFile( string filename ) 只需要为指定文件创建一个 XmlWriter 并调用 SaveFile( writer )。 对 SaveFile( XmlWriter writer ) 方法进行广泛的单元测试，您可以使用模拟 XmlWriter。 在 SaveFile( string filename ) 方法上测试一些错误条件 - 如果您希望处理它们而不是向上传播它们。 根据错误处理，您可能根本不需要创建文件。
顺便说一句，如果您不愿意，则无需直接使用 XmlWriter 公开您的方法。 您可以将其设为私有并使用访问器在测试中调用它。
Design your class so that you have SaveFile( string fileName ) and SaveFile( XmlWriter writer). SaveFile( string filename ) only needs to create an XmlWriter for the named file and call SaveFile( writer ). Do your extensive unit testing on the SaveFile( XmlWriter writer ) method for which you can use a mock XmlWriter. Test some error conditions -- if you expect to handle them instead of propagate them up -- on the SaveFile( string filename ) method. Depending on the error handling you may not need to create a file at all.
BTW, you don't need to expose your method using the XmlWriter directly if you don't want to. You could make it private and use an accessor to invoke it in your tests.