Best practices for testing with Rspec?

[sumit...@gmail.com]

Aloha!

Are there any best practices for being able to create specs around file upload?  Even if just to stub out the stuff that does heavy work but lets me know that attachments are being set so I can test everything around it.  I was about to do a deep dive into the internals to see what I needed to stub out but if there's something already in place to do this I'd completely rather use that. 

Cheers!

Sumit

[Janko Marohnić]

Aloha!

At the moment there isn't anything in Shrine specific for testing, but I can provide a few opinions that come to mind.

Firstly, what I saw in Refile that it exposed a FileDouble for "easier" testing. Why I mention this is because Shrine conforms to the same IO interface. However, I would recommend that for testing real files are used, or IOs that are used by your application (e.g. ActionDispatch::Http::UploadedFile).

Storages are very easily tested directly, you just instantiate them with the symbol name of the registered storage:

image = File.open("test/fixtures/image.jpg")
uploader = ImageUploader.new(:store)
uploaded_file = uploader.upload(image)
# further assertions on uploaded_file

When you're testing an uploader directly, it's good to test processing. However, when you have more higher-level tests, you might want to disable processing, and in case of versions simply conform to the interface:

before do
  allow_any_instance(ImageUploader).to receive(:process).and_wrap_original do |m, io, context|
    if context[:phase] == :store
      {small: io, medium: io, large: io}
    end
  end
end

For testing presigns, there has been some discussion already. The idea was to be able to swap S3 storages with FileSystem in tests (to eliminate HTTP), and that presigns are still generated for the FileSystem storage, just returning the URL to the direct upload route. I think this will soon land in master. However, these will probably only get tested in acceptance tests, and there it might be better just to use real storages anyway.

Cheers,

Janko

[sumit...@gmail.com]

Thank you!  

Personally testing the uploader itself feels a bit like testing configuration, but testing stuff like controller actions in my rails stack that sets shrine endpoints is definitely what I want to have access to. Going to take a whack at the stubbing around processing as you describe. 

Seriously thank you so much, this library has been a breath of fresh air in terms of how easy it is to work with especially once I got comfortable writing plugins. I still need to do some cleanup (and solicit advice on how best to wrap certain aspects of the functionality) into plugins like: my Zencoder one which instead of promoting to the store immediately fires off a background job, wrapping Imgix as a image processor so I never have to worry about bringing large images/pdfs into my dyno's memory, a "fix" (i think it still might be a hack) around rectifying an issue I was seeing around a Single Table Inheritance model where the records `type` changes between the time the UploadJob was enqueued and actually fired. 

Nothing but <3

[Janko Marohnić]

Thank you for such positive feedback! It's really great to hear that it's working out for you. I'm really motivated to continue improving Shrine, so I look forward to hearing your issues/suggestions.

Thanks,

Janko