トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

Gauge+Capybara+Rspecではじめる自動テスト

この記事はトレタ Advent Calendar 2020の15日目の記事です。

こんにちは。トレタでQAエンジニアやってます、中村です。 今年はGaugeを使ってE2Eテスト実装を行ったのですが、復習も兼ねて簡単に使い方をまとめてみようと思います。 この記事で説明しているコードはこちらに挙げてますので、一緒に見てみてください。

github.com

Gaugeとは

GaugeはThoughtWorks社がOSSで開発しているテスト自動化フレームワークです。 gauge.org 主な特徴として、以下が挙げられます。

  • 受け入れテスト自動化レイヤーのツール
  • テストの記述をmarkdownで可能
  • テストと実装を分けることができる
  • 自動テストに必要な機能が充実
    • TestRunner,Data-driven testing,Report,Screenshot,IDE
  • 多くの言語サポート
    • Java,Python,C#,Ruby,JavaScript

Seleniumでテスト自動化を行おうとするそれ以外の実装を行う必要が出てくるので、テストに必要な周辺機能がオールインワンで揃ってるのはうれしいところですね。

Gaugeのインストール

公式ドキュメントも詳細なので迷わずセットアップが可能です。 docs.gauge.org macの場合はbrew install gaugeでインストール可能です。

言語プラグインのインストールとプロジェクト作成

Gaugeをインストールしたら、次は言語プラグインをインストールします。 今回はRubyを指定しました。

gauge install ruby

インストール後は下記のコマンドでプロジェクト作成を行います。

gauge init ruby

プロジェクトディレクトリを作成したら、gauge run specs してテストを実行してみましょう。下記のようにテストがPassすればOKです。

f:id:gonkm:20201215033429p:plain

CapybaraとRspecの導入

今回はGaugeを使ってブラウザテストを行うため、CapybaraとRspecを導入します。 Gemfileに下記を追記して、bundle installします。

gem 'rspec'
gem 'selenium-webdriver'
gem 'capybara'

インストールが完了したらstep_inplementaions内に、spec_helper.rbを準備します。 Execution Hooksbefore_suiteにテストスイート実行前にCapybaraを起動するための記述を追加しています。 またGauge.configure経由でCapybara::DSLRSpec::Matchersをincludeします。 Gauge.configureにはScreenshot取得のための記述も追加しておきます。

require 'capybara/dsl'
require 'capybara/rspec'
Bundler.require

Capybara.default_driver = :chrome

before_suite do
  Capybara.register_driver(:chrome) do |app|
    options = Selenium::WebDriver::Chrome::Options.new
    options.add_argument('--headless')
    options.add_argument('--window-size=1400,1400')

    Capybara::Selenium::Driver.new(app, browser: :chrome, options: options)
  end
end

Gauge.configure do |config|
  config.include Capybara::DSL
  config.include RSpec::Matchers
  config.custom_screenshot_writer = -> {
    file = File.join(config.screenshot_dir, "screenshot-#{(Time.now.to_f*10000).to_i}.png")
    Capybara.page.save_screenshot(file)
    File.basename(file)
  }
end

テストの実装とテストケースの作成

テストケースの作成を行うには、markdown内で利用するstepの実装が必要です。 step_inplementaion.rb内に、下記の内容を記述します。

step 'Googleで「トレタ」と検索する' do
  Gauge.write_message 'Googleへ遷移'
  visit('https://www.google.com/?hl=ja')
  find('input[name="q"]').set('トレタ')
  find('input[name="btnK"]').click()
  Gauge.capture
  expect(page).to have_content('株式会社トレタ(Toreta,Inc.)')
end

Capybaraのコードに加えて、テストの結果出力のために下記を記述しています。

  • Gauge.write_message:指定した文字列を出力
  • Gauge.capture:bowスクリーンショットの取得

テストケースはspecs内にXXX.specという拡張子で作成します。 以下のように、sample.specを作成し、実装したstepを記述します。

# Googleでトレタを検索する

## Googleでトレタを検索する

* Googleで「トレタ」と検索する

テストの実行とレポートの確認

テストの実行はspecファイルを指定して実行します。

gauge run specs/sample.spec

f:id:gonkm:20201215043118p:plain

出力されるHTMLレポートは下記の通りです。 stepで実装した文字列とスクリーンショットも反映されています。

f:id:gonkm:20201215043626p:plain

データ駆動型テストの実装

前述の通り、Gaugeではデータ駆動テストをサポートしています。 markdownにデータテーブルを準備し、stepでパラメータを受け取るようにすることで、実装が可能です。 先程実装したテストをデータ駆動型に書き換えてみます。

sample2.spec

# Googleでトレタのサービスを検索する

| keyword                   | result                                                  |
|-------------------------- |---------------------------------------------------------|
| トレタ予約台帳              | あらゆる飲食店・レストランの繁盛を支える予約台帳/顧客台帳サービス  |
| トレタかんたんウェブ予約      | 無料でウェブ予約ページの作成が可能                            |
| トレタnow                  | グルメの、超直前予約アプリ                                   |

## Googleでトレタのサービスを検索し、検索結果を確認する

* Googleで「<keyword>」と検索する
* 検索結果に<result>が含まれていることを確認する

step_inplementaion.rb

step 'Googleで「<keyword>」と検索する' do |keyword|
  Gauge.write_message 'Googleへ遷移'
  visit('https://www.google.com/?hl=ja')
  find('input[name="q"]').set(keyword)
  find('input[name="btnK"]').click()
end


step '検索結果に<result>が含まれていることを確認する' do |result|
  Gauge.capture
  expect(page).to have_content(result)
end

結果

どのデータテーブルのテストかがわかりやすく表示されます。

f:id:gonkm:20201215051343p:plain f:id:gonkm:20201215051357p:plain

実際に導入してみて

今回の記事ではブラウザテストベースでの使い方をまとめましたが、弊社での実際の使い方としてはトレタ予約台帳と外部連携しているAPIに対して導入しています。 外部連携ではテストの事前準備として連携各社様の予約画面からブラウザを操作して予約を作成する必要があったためです。

APIテスト単体であればPostmanで事足りますが、手順が長く複雑なE2Eレベルのテストシナリオをユーザー操作レベルで記述するという面では、Gaugeのように自然言語でドキュメンテーションを残せるのは大きなメリットがあっため、今回採用してみました。 前提条件を作成するための手順が長い場合は、Conceptを作ることでspec上の記述を簡略化させたりできるため、冗長な記述を避けることができる点もよかったです。

テストの実装タイミングは保守開発が進んでいる状況だったのでエンハンスやバグ修正のテストを実装しつつ、リグレッションテストを増やしていきました。現在ではCircleCIで週1で定期実行を行っている状態です。

最後に

現在トレタは新しい取り組みを多く進めています!興味のある方はぜひとも遊びに来てください!

corp.toreta.in

© Toreta, Inc.

Powered by Hatena Blog