使用 Minitest 測試 Carrierwave 上傳

Question

只是嘗試向我的 Carrierwave 上傳器添加一些基本測試。 我從默認生成的測試開始，並嘗試從那里開始。 我收到一個奇怪的錯誤，不知道從哪里開始。

我有一個多態Upload模型，它具有：

mount_uploader :file, DocumentUploader

我的 DocumentUploader 有這樣的東西：

  def store_dir

    "#{model.uploadable_type.downcase.pluralize.underscore}/#{model.parent_asset.id}/uploads/#{model.id}/"

  end

這使我的商店目錄看起來像：

/locations/24/uploads/56

例如，當我運行默認測試時：

  test "should destroy upload" do
    assert_difference('Upload.count', -1) do
      delete :destroy, id: @upload
    end

    assert_redirected_to uploads_path
  end

我得到：

ERROR["test_should_destroy_upload", UploadsControllerTest,1.9893769259997498]
test_should_destroy_upload#UploadsControllerTest (1.99s)
NoMethodError: NoMethodError: undefined method `id' for nil:NilClass
            app/uploaders/document_uploader.rb:34:in `store_dir'

在我的上傳裝置中，我設置了多態關聯等。 model沒有被設置為 DocumentUploader 中的 Uploadable 關聯，即它為零。

到目前為止，我的所有其他測試都工作正常，我的上傳器在生產和開發等方面工作正常。我確信我在設置中遺漏了一些微不足道的東西，或者這是 Carrierwave 的特定問題。

Answer 1

在這里打招呼真的很晚。

我發現使用帶有carrierwave的fog是一種阻力。 對我來說， carrierwave-aws gem 沒有商量余地。

自述文件提供了一個快速的整體存根以添加到uploads.rb配置文件中：

config.aws_credentials = {
  [...], # Required
  stub_responses:    Rails.env.test? # Optional, avoid hitting S3 actual during tests
}

對於表示層，我認為這是可以接受的，因為您經常希望看到結果，尤其是這些結果的版本。 一旦這些運行正常，如果方法不改變，它們就很難被破壞——而且這些是相當靜態的方法。