Stubbing

double 可以讓我們輕易地閃掉準備「協作者」的痛苦。但是有時候,我們還是可能被「協作者」本身的內部邏輯改變整到。

比如說,這裡是一個「建議」Suggestion 表單:

require "rails_helper"

RSpec.describe SuggestionsController, type: :controller do

  describe "POST create" do
    context "when suggestion is invalid" do
      it "render new" do
        post :create, :suggestion => { :title => "", :description => "" }

        expect(response).to render_template :new
      end
    end
  end
end
class Suggestion < ActiveRecord::Base
  validates :title, presence: true
end
class SuggestionsController
  def create
    @suggestion = Suggestion.new(suggestion_params)

    if @suggestion.save
      redirect_to root_path
    else
      render :new
    end
  end

  protected

  def suggestion_params
    params.require(:suggestion).permit(:title, :description)
  end
end

如果物件非法的話,要 render new 這個 action。正常來說,這樣的 controller 測試,應該會通過。但是有時候 controller 程式碼沒有動,但 model 程式碼內部動了,比如說在這個例子,可能多加了新的欄位,或者是新增了其他的驗證方式,導致這個 controller 測試要因為 suggestion 內部本身的邏輯要修改。

這樣真的很討厭。

重寫測試

其實這裡我們根本不應該塞「例子」進去,這樣 suggestion 內部邏輯一旦改變,我們的 controller test 就要改個沒完。我們真正應該要做的是:

  • 準備一個「一定儲存失敗的替身」
  • 然後在 controller 讓 @suggestion.save 鐵定失敗
  • 因為我們要驗證的是 「render :new

所以我們可以把測試改寫成這樣

require "rails_helper"

RSpec.describe SuggestionsController, type: :controller do
  describe "POST create" do
    context "when suggestion is invalid" do
      it "render new" do
        invalid_suggestion = double(:save => false)

        allow(Suggestion).to receive(:new).and_return(invalid_suggestion)

        post :create, :suggestion => { :xxx => "yyy" }

        expect(response).to render_template :new
      end
    end
  end
end

這樣 suggestion 內部驗證再怎麼樣變,都不會影響到這個 controller test。

results matching ""

    No results matching ""