对以文件名作为参数的方法的测试和正确放置感到困惑
我有一段代码，它使用 .mp3 文件的文件路径生成类 Id3v1Tag。我在 WPF MVVM 应用程序中使用它，并且像许多其他人一样，一直痴迷于以“正确”的方式设计我的应用程序，因此我试图找出将这段代码放在哪里。最初它位于 Id3v1Tag（继承的代码库）的构造函数中，但我将其取出并放入一个名为 Id3v1TagService 的类中。但是测试呢？既然它需要一个文件名作为参数，那么它现在不是依赖于文件服务吗？
I have a piece of code that generates a class, Id3v1Tag, using a file path to an .mp3 file. I am using it in a WPF MVVM app and, like many others, have become obsessed with designing my applications the 'right' way, so I am trying to figure out where to put the piece of code. Initially it was in the constructor for Id3v1Tag (inherited code base), but I took it out and put in a class called Id3v1TagService. But what about testing? Since it takes a filename as a parameter, isn't it now dependent on the file service?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您需要将文件的加载与服务中的其他逻辑分开。源可能存在于由文件名标识的磁盘上这一事实与 Id3v1TagService 无关。相反，传递一个流。有关打开/关闭文件的逻辑属于不同的类。
这是一个更好的设计，因为：-
您仍然需要测试打开/读取的类/ 关闭文件。这不可避免地需要访问文件系统（因为这就是重点）。如果它很简单并且没有单元测试，您可以将其留给集成测试。
You need to separate the loading of the file from the other logic in your service. The fact that the source may exist on disk identified by filename is not relevant to Id3v1TagService. Instead pass it a stream. The logic about opening/closing the file belongs in a different class.
This is a better design because:-
You will still need to test the class that opens/reads/closes the file. It's inevitable that this needs to hit the filesystem (since that's the point). You could leave this to integration tests if it's trivial and not have a unit test.
您将需要传入文件访问对象，无论它是什么（这是依赖项注入的一部分），因为这样您就可以在以后模拟它并仅测试您要测试的类的功能。
存储库类、服务或任何进行文件访问的内容都应该使用其中的文件路径。
You'll want to pass in your file access object, whatever it is (this is part of dependency injection) because then you can mock it down the road and test ONLY the functionality of the class you are trying to test.
The repository class, or service, or whatever is doing your file access, should use the filepath in it.