Appiumを使ってRSpecの記述とTurnipの記述とで、結局はどちらが受け入れとして使えそうか

比較的、ぱっと見て操作を想像できることが受け入れ試験では大事だと思います。
そう考えると、RSpecはshared_exampleなんかで操作をまとめることができるのですが、Turnip/Cucumber形式のシナリオアウトラインを使った方が綺麗にかけそう。

一方、capybaraのように、RSpecの拡張としてFeature specを使うこともできる形があります。なら、Appiumを使って同様に受け入れ試験の形を模倣するならば、CapybaraのFeature specを参考に類似した記述を模倣すれば、RSpecのみである程度読みやすい受け入れ試験もかけるかもと思い、以下をまとめてみた。

受け入れを考える場合、今の開発スタイルを重視すると、Storyがあって、そのStoryに対する受け入れを実施したい。可能であれば、Storyごとに、ユーザの状態が異なる状態での振る舞いの変化をまとめていきたい。

以下がshared_exampleを使って、RSpecで愚直に書いてみた。

describe "basic functions"

  describe "guest user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
  do

  describe "no-premium user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
    it_behaves_like "for nonpremium users"
  do

  describe "premium user" do
    before :all do
      #nothing special
    end
    it_behaves_like "for all users"
    it_behaves_like "for premium users"    
  end
end

それに対して、以下のようにTurnipを使って書いた。

Scenario Outline: sample scenario
  Given test with <device>
  When login with <user_status>
  When do something
  Then goal

  Examples:
    |  device  |  user_status  |
    | 'iphone' | 'nonpremium' |
    | 'iphone' | 'premium'     |

このとき、 When do something の箇所は極力共通なステップで記述できることが必要ですね。

受け入れ試験として最終的に受け入れられるべきは、Story単位で行うのであれば”xxxができる”というシナリオにしたいので、Story baseの開発スタイルでは管理しやすいと思う。なので、Scenario Outlineでかけることの方が受け入れ試験では重視すべきなのかな。
こう比べてみると、TurnipやCucumber、シナリオ単位で記述するのに役立つのね。
RSpecでも同様にかけるのかな。※知識不足です。。。

もう少し話を進めて、cabybaraを使ったFeature Specを模倣して、scenarioに該当する箇所を定義し、その中でshared_exampleを定義してguest/non-premium/premiumユーザの状態でシナリオを書いてみた。

require "spec_helper"

feature "Widget management" do
  scenario "User creates a new widget" do
    do something
  end
end

がFeature specの例文として、このfeature/scenarioの記述を参考にRSpecのdescribeなどを書いてみる。

  • pure rspec
require "spec_helper"

describe "do something" do

  shared_examples 'login with nonpremium user'
  shared_examples 'login with premium user'

  describe "Users do sample scenario" do
    context 'guest user' do
      it 'do something'
    end

    context 'nonpremium user' do
      shared_examples 'login with nonpremium user'
      it 'do something'
    end

    context 'premium user' do
      shared_examples 'login with premium user'
      it 'do something'
    end
  end
end
  • with parametaraized gem
require "spec_helper"

describe "do something" do

  shared_examples 'login with nonpremium user'
  shared_examples 'login with premium user'

  describe "Users creates a new widget" do

    where_table(:user_status) do
         'guest'
         'nonpremium'
         'premium'
    end

    with_them do
      login_with :user_status
      do something
    end

  end
end

※動作検証はしていないですが、書き方としてはこんなものかな、という程度の記述です。

こう書いているのをみると、やはりシナリオベースで何か検証事項を書く場合はTurnipのほうが読みやすいな。。。
次は管理すべきファイルの種類だけれど、TurnipはRSpecの拡張として扱えるとはいえ、.featureと_steps.rbを管理する必要がある。ただし、これはある程度操作を簡単・共通化できる場合、さほど煩雑ではない。

こう考えると、いったんはTurnipで進めるのが無難かな、と思う。
ついでにいうと、Cabybaraのextentionsを使えるのですね。Turnipで。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中