我正在尝试编写单元测试的习惯,我之前已经写了几个,但是它们通常是相当基本的…我想开始向TDD转移,因为我想提高质量我的代码(设计和结构) – 减少耦合,同时希望减少回归到可测试版本的回归数.
我采取了一个比较简单的项目,我开始工作.结果程序观看一个文件夹,然后对该文件夹中的文件进行操作.
private string RestoreExtension(String file)
{
var unknownFile = Path.GetFileName(file);
var ignoreDir = Path.GetDirectoryName(file) + "\\Unknown";
string newFile;
//We need this library for determining mime
if (CheckLibrary("urlmon.dll"))
{
AddLogLine("Attempting to restore file extension");
var mime = GetMimeType(BufferFile(file,256));
var extension = FileExtensions.FindExtension(mime);
if (!String.IsNullOrEmpty(extension))
{
AddLogLine("Found extension: " + extension);
newFile = file + "." + extension;
File.Move(file,newFile);
return newFile;
}
}
else
{
AddLogLine("Unable to load urlmon.dll");
}
AddLogLine("Unable to restore file extension");
if (!Directory.Exists(ignoreDir))
{
Directory.CreateDirectory(ignoreDir);
}
var time = DateTime.Now;
const string format = "dd-MM-yyyy HH-mm-ss";
newFile = ignoreDir + "\\" + unknownFile + "-" + time.ToString(format);
File.Move(file,newFile);
return String.Empty;
}
问题：
如何使用IO测试方法？
我真的不想使用一个真正的文件,因为这将是缓慢的(和更多的集成测试？),但我不能真正看到另一种方式.我可以添加一个可切换的IO抽象层,但这听起来像我可能不必要地使代码复杂化…
这样的项目是否值得单位测试？
我的意思是说,这太简单了.一旦你脱掉了.Net和第三方图书馆的电话,没有多少剩下的这么一个案例,使得它可测试的工作量意味着它不是一个很好的候选人测试？
这个项目中的很多方法都是私有的,因为这个项目恰好是Windows服务.我读过你应该只是真正测试外部可见的方法(公开或通过界面暴露),但是在这种情况下,我不太可能会公开我自己的任何方法.这个项目是否值得测试(因为id可能需要将方法访问修饰符更改为public或添加一些属性,以便NUnit可以看到它们)？
干杯
解决方法
关于如何测试文件I / O：
这样做的一个常见方法是将File I / O封装在包装器类中.例如：
这样做的一个常见方法是将File I / O封装在包装器类中.例如：
public class FileHandler : IFileHandler
{
public string GetFilename(string name)
{
return System.IO.GetFileName(name);
}
public string GetDirectoryName(string directory)
{
return System.IO.GetDirectoryName(directory);
}
}
public interface IFileHandler
{
string GetFilename(string name);
string GetDirectoryName(string directory);
}
在您的测试方法中,您只能针对该接口进行编程.运行单元测试时,您将使用返回预定义值的模拟对象.为此,您可以使用Moq.
这是一个有点工作,但是你不需要测试文件I / O.
最好一月
