单元测试,重构,IO

时间:2009-01-19 16:42:11

标签: c# unit-testing refactoring

你有一个有2个参数的类的方法,其中一个是文件路径,另一个是不相关的。

InterestingResult result = foo.Bar(irrelevant, filePathInfo);

本着快速快速单元测试的精神,你发现自己正在考虑重构这个方法来拉出文件路径来删除这个测试的IO要求...最有可能把它放到另一个方法中,所以现在你会致电

string dataInFile = foo.GetDataInFile(filePathInfo);
InterestingResult result = foo.Bar(irrelevant, dataInFile);

你疯了吗?......或者这是件好事吗?

5 个答案:

答案 0 :(得分:6)

如何使用Stream作为参数呢?这样,您就可以在单元测试中传递MemoryStream,在生产代码中传递FileStream

答案 1 :(得分:0)

作为一般规则,我会避免仅为测试目的而更改界面。接口应该反映用户的需求,而不是开发人员或测试人员的需求。

答案 2 :(得分:0)

取决于你的要求。有些人会说设计用于测试。我不会仅仅为了适应测试而改变我的设计。

但在这种情况下,我更改我的设计,以便Foo方法采用Stream而不是文件路径。这样它就更灵活,你的单元测试只能传递一个虚拟流。

答案 3 :(得分:0)

我可能会设计接口,这样我就不会传入文件路径,而是传入一个IStream(或类似的)指针。这样你就可以使用Mock库进行测试,传入一个满足方法的模拟IStream,并提供更强大的测试。

答案 4 :(得分:0)

最简单的方法。

  • 为了您的测试,提供一个(只读)golden file,您知道它的预期输出。(将其存储在Test / Resources中)。如果这足够快,则无需更改生产代码。
  • 如果测试命中FileSystem的速度非常慢(超过半秒),则抽象出FileSystem Access(使用模拟/假)(类似于你问题中的第二个片段)。

随着越来越多的测试被感染,你会产生一种蜘蛛般的感觉,这些东西可能会相应地进行测试和设计。所以坚持下去......

相关问题