【发布时间】:2016-08-20 01:03:22
【问题描述】:
想象一个这样的类:
public class FileParser : IFileParser
{
public string ParseFirstRowForDelimiters(string path)
{
using (TextFieldParser parser = new TextFieldParser(path))
{
string line = parser.ReadLine();
if(lineContains("'"))
{
return "'";
}
if(lineContains("\"")
{
return "\"";
}
return "";
}
}
}
对于依赖于 FileParser 的类,我可以通过它的接口模拟它的功能,一切都很好。但是,类本身的逻辑依赖于 TextFieldParser 返回一行来检查。
我不能用模拟“接口”TextFieldParser 来对该逻辑进行单元测试,因为它是来自微软的一个没有接口的外部类。
我可以将 if 语句推到单独的函数中,如下所示:
public bool HasSingleQuote(string lineToCheck)
{
return lineToCheck.Contains("'");
}
但是这些不需要在课堂之外访问。它们也不需要从其他地方调用,因此它们不属于辅助类或类似的类。因此,根据良好的设计原则,它们是私有的而不是公共的,我应该通过它们的公共访问器来测试它们。在这种情况下,这取决于不可测试的 TextFieldParser。
我可以将 TextFieldParser 包装在我自己的类中并在其上粘贴和接口,但这感觉像是过度杀伤和不必要的代码复制。
我很欣赏这是一个不值得测试的微不足道的例子,但我只是把它放在一起来说明这个问题。重构此代码以使我的逻辑可测试的最佳方法是什么?
【问题讨论】:
-
我会说测试你拥有的东西。
TextFieldParser是一个实现细节。 MS 会广泛测试它的发布功能。如果担心的是您正在执行条件检查的其实现内部的逻辑,那么可以认为IFileParser实现可能做了太多事情。我想起了 SRP,只有一个理由改变。 -
顺便说一句,《有效地使用遗留代码》是一本很棒的书。 informit.com/store/… 第 14 章和第 15 章肯定适用于此。
标签: c# unit-testing architecture refactoring