受け入れ試験レベルの抽象度のシナリオを、Appium x “RSpec or Turnip”で比較してみた

最近、スマホアプリの受け入れテストの機能的側面を自動化する場合、どのような手段が妥当なのか？ということを考える。
それを、Appiumを基本に、RSpecとTurnipの2つを中心に比較して考えてみる。

どちらを選択したら良いのかなということに対して結論からいうと、何がよいのかという判断自体は
– 誰が受け入れ試験のシナリオを記述するか
– 誰が自動化コードをメンテするか
– どのような開発スタイルか

に大きく依存しますかね。

ここで、RSpecに寄せた場合、おそらくエンジニアが少なくない量の受け入れ試験用コードを書くことになるでしょう。エンジニアが受け入れ試験の言葉を理解することは、ユビキタス言語を生み出すので、おそらく内部品質まで議論が及んだときにドメインと結びつけることができる可能性が高い、という側面は利点。

一方、企画や営業系の方が受け入れ試験を書く、とした場合、より独立性の高い受け入れ試験のストーリー作れますかね。ただ、結構難易度高いかもしれないですね。なんだかんだて、かなりストーリーを細かくする必要もでてくるので。

そこらへんの利点、欠点を比べてみると、やはりメンテはエンジニアが関わることになるか。また、RSpec程度であれば人が可読できるレベルの記述は可能なので、受け入れ試験として記述することも難しくない、かな。

理想をいえば、受け入れ系はエンジニアから独立しているほうが良いのかもしれないけれど、そもそも仕様の妥当性を評価して正しい方向に持っていくというようなリーン開発のような場合、素早く保守できる体制を維持するほうが価値が高いのかなと思ったり。

例: Turnipで。stepsファイルはのぞく。（以下の場合のstepsの規模は、RSpecと同等）

Feature: acceptance test
  Scenario: display the result of google search
    Given test with 'iphone6_ios7'
    Then go to 'https://google.com'
    Then input 'ゆき' in search field
    Then submit form
    Then display search page ?
    Then save screenshot '1'

ここで.featureファイルをすべてRSpecで記述すると、

    context 'search ゆき' do
      let(:word) { 'ゆき' }
      let(:url) { 'http://google.com' }

      it 'URLにhttp;//google.comを入力する' do
        appium_driver.get(url)
      end

      it 'Googleの検索欄に"ゆき"と入力する' do
        appium_driver.find_element(:id, 'lst-ib').send_keys(word)
      end

      it '検索を開始する' do
        appium_driver.find_element(:id, 'tsf').submit
      end

      it '検索結果が表示された？' do
        expect { driver_wait(3).until { appium_driver.find_element(:id, 'hdtb_msb') } }.not_to raise_error
      end

      it 'スクリーンショットを撮る' do
        save_picture_as(@device.to_s)
        driver_cleanup
      end
    end

のようになる。
多分に省略した箇所はあるのですけど、行数だけみると、”書きたいこと”に注力できるのはTurnipのように見える・・・
一方で、stepsファイルがTurnipの場合は一つかまされるようになります。このファイルの保守性自体はRSpecと同程度ですかね。それに加えて.featureファイルのメンテも必要。

柔軟性との兼ね合いも考えると、どうしてもRSpecに傾いてしまう・・・
勤め先に適用するとした場合、RSpecのほうが保守性が明らかに高くなりそう。

今度は実際に小さなプロジェクトで効果を検証してみようかな。。