1

統合テストを整理する方法について少し混乱しています。現在、これらはページ構造に従って編成されています。

post_pages_spec.rb：

require 'spec_helper'

describe "Post pages" do

  describe "show page" do

    describe "post destruction" do

    end

    describe "edit" do

    end

  end

  describe "post creation" do

  end


end

ご覧のとおり、削除と編集は表示ページに表示されるため、表示アクション内にあります。

これは、（RESTアクションに基づいて）それらを整理する別の方法です。

post_pages_spec.rb：

require 'spec_helper'

describe "Post pages" do

  describe "show page" do

  end

  describe "post destruction" do

  end

  describe "post creation" do

  end

  describe "edit" do

  end
end

どの構造がより明確で維持しやすいですか？

4

1 に答える 1

2

コントローラーテストではなく統合テストについて実際に質問していると仮定すると、ユーザーの観点から、ユーザーのタイプごとに統合テストを整理するのが好きです。元。登録ユーザー用に1つのファイル、管理者用に1つのファイル、未登録ユーザー用に1つのファイルなど、必要に応じて。

これを正当化するのは、一般的なヒューリスティックとして、同じユーザータイプが機能の同じ前提条件を持っているため、うまく適合していることを発見したことです。たとえば、投稿を表示している登録ユーザーには、既存の投稿コンテンツのCRUDに焦点を当てた多くのシナリオがあり、未登録ユーザーには、投稿の推奨に焦点を当てたシナリオがあります。これらの異なるパースペクティブではセットアップとティアダウンが異なる可能性が高いため、個別に保守する方が簡単である可能性もあります（つまり、DRY-erなど）。

また、それはいい読みです:)例：

describe "Registered User" do
  context 'creating a Post' do
    it "succeeds given all fields are filled out"
    it "displays errors to the author if a field is missing"
  end
end
于 2012-11-11T22:49:50.947 に答える