Create a mock request that will handle cffile action = upload

Question

I am writing a boot function for ColdFusion of Wheels and it needs a unit test after its completion. The problem I am facing is that I have no idea how to create a multi-component layout in ColdFusion, which I can use in my unit tests.

What I would like to do is create a mock request that mimics a downloadable file that cffile can handle, and I could check it out.

I saw in the online help ColdFusion , an example of creating such a request using cfhttp, however it should publish on another page, the kind of defeats that is the whole goal.

Answer 1

Great question. For what it's worth, I contribute to MXUnit (wrote the eclipse plugin), and this script appeared in a presentation I made at cfobjective this year, while writing simpler code ( http://mxunit.org/doc/zip /marc_esher_cfobjective_2009_designing_for_easy_testability.zip ).

In this case, I suggest NOT testing the download. I believe that we should not waste time testing, not our code. The likelihood that we will catch a mistake or other strangeness is low enough for me to justify its unverified. I believe that we should test "our" code.

In your scenario, you have two behaviors: 1) loading and 2) post-loading behavior. I would test the behavior after loading.

Now this frees up your unit test so as not to care about the source of the file. Notice how this actually leads to untying the loading logic from "what should I do with the file?" logics. To summarize, this at least creates the potential (theoretically) for reusing this logic after loading for other things besides just downloading.

This simplifies your test because now you can just test the file you put somewhere in the setUp of the unit test itself.

So your component changes from

<cfffunction name="uploadAndDoStuff"> 

to

  <cffunction name="upload"> 

and then

 <cffunction name="handleUpload"> 

or "handleFile" or "doSomethingWithFile" or "processNetworkFile" or something else. and in your unit test you leave upload () unchecked and just check your post-upload handler. For example, if I did this at work, and my requirements were: "Upload a file, move the file to the queue for virus scanning, create thumbnails if the image or jpg; add material to the database, etc.", then I would I saved each of these steps as separate functions, and I tested them in isolation, because I know that “upload file” already works, since it worked with CF1.0 (or something else). It makes sense?

Even better, leave the “unloading” of the component completely. There is nothing wrong with keeping it in a CFM file, because in an attempt to generalize it there is not so much (as far as I see). there may be benefits when taunted, but that's a completely different topic.

Answer 2

I quickly searched for MXUnit when the form loaded and created this google groups thread: Testing file upload

His discussion is between Peter Bell and Bob Silverberg, the result of which is that file download testing is actually part of acceptance testing, not unit test.

I know that does not strictly answer your question, but I hope this helps.

Answer 3

Strictly speaking, you are right. If you need to go out to call an external resource, check something (database, web service, file downloader), it really defeats the purpose of unit testing. The best general advice is to mock the behavior of external resources and assume that they are functioning or covered by their own unit tests.

Pragmatism can change this, although on the basis of Model-Glue code we have a number of unit tests that access external resources, for example, for constant values ​​through redirection, linking the functionality of AbstractRemotingService and so on. They were considered quite important functions for the unit test, and we decided to make the external dependencies of our unit tests to ensure good coverage. After all, there are no acceptance tests in the framework code. Our users do it, and users of the structure expect flawless code, as they should.

So, there are cases when you want to test a vital external resource and want it to be processed using an automated function, it makes sense to add it to your unit tests. Just know that you are deviating from best practices that exist for a reason.

Dan wilson