创建一个模拟请求,cffile action=upload将处理该请求

很好的问题。值得一提的是,我为MXUnit做了贡献(编写了Eclipse插件),这个场景出现在我今年在cObjective做的关于编写更容易测试的代码的演示中。( http://mxunit.org/doc/zip/marc_esher_cfobjective_2009_designing_for_easy_testability.zip )

在这种情况下,我建议不要测试上传。我认为我们不应该花时间测试那些不是我们的代码的东西。我们抓住一个bug或其他奇怪的东西的可能性对于我来说足够低,我可以不去测试它。不过,我认为我们应该测试“我们的”代码。

在您的场景中,您有两种行为:1)上传和2)上传后行为。我会测试上传后的行为。

现在可以释放单元测试来不关心文件的源代码。请注意,这实际上是如何将上载逻辑与“如何处理文件”分离的?逻辑。综上所述,这至少创造了一种潜力(理论上),可以将这个上传后逻辑重用到上传以外的东西上。

这使您的测试更加容易,因为现在您可以只针对您在单元测试本身的设置中放置的某个文件进行测试。

所以您的组件从

<cfffunction name="uploadAndDoStuff">

到

 <cffunction name="upload">  

然后

<cffunction name="handleUpload"> 

或“handlefile”或“dosomethingwithfile”或“processnetworkfile”或其他东西。在单元测试中,您不需要测试upload(),只需要测试post upload处理程序。例如,如果我在工作中这样做,我的要求是:“上传文件;将文件移动到队列中进行病毒扫描;如果是图像或JPG,则创建缩略图;将资料添加到数据库中;等等”,那么我将把这些步骤中的每一个作为单独的功能保留,并且我将对它们进行隔离测试,因为我知道“上传文件”自CF1起就已经起作用了.0(或其他)。有道理?

更好的是,让“上传”完全离开组件。把它保存在一个cfm文件中没有什么错,因为在尝试将它进行genericize方面没有太多的意义(据我所见)。在嘲笑的问题上可能会有好处,但这完全是一个不同的话题。

我快速搜索了一个MXUnit,测试了一个表单上传,并想出了这个谷歌群组线程: Testing a file upload

这是彼得·贝尔和鲍勃·西尔弗伯格之间的一个讨论,其结果是测试文件上传实际上是验收测试的一部分,而不是单元测试。

我知道这并不能严格回答你的问题,但我希望能有所帮助。

严格来说你是对的。如果你必须出去调用一个外部资源做一些测试(数据库,Web服务,文件上传器),它确实破坏了单元测试的目的。最好的一般性建议是模拟外部资源的行为,并假设它们起作用或由它们自己的单元测试覆盖。

尽管实用主义可以改变这一点,但是在模型粘合框架代码库上,我们有许多调用外部资源的单元测试,比如跨重定向持久化值、连接AbstractRemotingService功能等等。这些特性被认为对单元测试足够重要,我们选择使单元测试的外部依赖性确保良好的覆盖。毕竟,在框架代码中,没有验收测试。这些都是由我们的用户和框架的用户完成的,他们希望代码没有缺陷,因为他们应该这样做。

因此,在某些情况下,您希望测试一个重要的外部资源,并且希望它由一个自动化函数处理,将其添加到单元测试中是有意义的。只要知道你偏离了最佳实践,那是有原因的。

丹威尔森