<-- mermaid -->

GaugeのParameterを使いこなす

こんにちは! SPEEDA日本事業部でテストエンジニアをやっている工藤です。

Gaugeシリーズの第三回目です 第二回目の記事はこちらから

今回はGaugeの「Parameter」について書きます。 ParameterはGaugeでテストを書くにあたり、基礎的かつ重要な機能です。

Parameterとは

GaugeのStepはパラメータを受け取ることができます。 Parameterを使いこなすと、Stepの再利用性をさらに高めることができます。

GaugeのParameterの機能はかなり充実していて、主に下記のようなParameterがあります。

  • Simple Parameters
  • Dynamic Parameters
  • Table Parameters
  • Special Parameters

今回はSimple ParametersとDynamic Parametersについて書きます。

Simple Parameter

Simple Parameterはその名の通り一番シンプルで、Stepに渡したい値をダブルクォーテーションで囲みます。
* Go to "Top" page

例えば、下記のようなSpecファイルがあります。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームに日本ユーザーのログイン名を入力
* ログインフォームに日本ユーザーのパスワードを入力

## 中国ユーザーとしてログイン
* ログインフォームに中国ユーザーのログイン名を入力
* ログインフォームに中国ユーザーのパスワードを入力

テストコードでは4つのStepに対応したメソッドを記述する必要があります。
login.kt

class login {
  @Step("ログインフォームに日本ユーザーのログイン名を入力")
  fun fillInJpnUserName() =
        `$`(".username").sendKeys("jpn_user")

  @Step("ログインフォームに日本ユーザーのパスワードを入力")
  fun fillInJpnUserPassword() =
        `$`(".password").sendKeys("passwprd_jpn")

  @Step("ログインフォームに中国ユーザーのログイン名を入力")
  fun fillInForeignUserName()  =
        `$`(".username").sendKeys("chn_user")

  @Step("ログインフォームに中国ユーザーのパスワードを入力")
  fun fillInForeignUserPassword() =
        `$`(".password").sendKeys("passwprd_chn")
}

SPEEDA開発チームではSelenide × kotlinでテストコードを書いています。

そこで以下のようにパラメータを使えば同じStepを使いまわすことができます。
login.spec

## 日本ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"jpn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_jpn"を入力

## 中国ユーザーとしてログイン
* ログインフォームにユーザーのログイン名"chn_user"を入力
* ログインフォームにユーザーのパスワード"passwprd_chn"を入力

そうするとテストコード側のStepの記述も減ります。
login.kt

class login {
  @Step("ログインフォームにユーザーのログイン名<userName>を入力")
  fillInUserName(userName: String) =
        `$`(".username").sendKeys(userName)

  @Step("ログインフォームにユーザーのパスワード<password>を入力")
  fillInUserPassword(password: String) =
        `$`(".password").sendKeys(password)
}

上記の例で示したようにParameterなしだとユーザー毎にStepを作成しなければいけません。 しかしParameterを利用することでステップの再利用性が上がり、結果としてテストコードの記述量も減らせます。

Dynamic Parameters

Simple Parametersと同じくらい多用するのが、Dynamic Parametersです。 Dynamic Parametersには主に下記二つの用途があります。

  1. Conceptに値を渡す
  2. Data Driven Executionをする際に、テーブルの値を参照する

Conceptに値を渡す

まずはこちらの用途から見ていきます。
Dynamic ParameterとConceptを使うと、Specファイルの可読性を上げることができます。 ConceptファイルでDynamic Parameterを利用してConceptを定義します。
<>内で指定したフィールド名を使うと、Concept下のStepでもその値を利用することができます。
login.cpt

# ユーザー<userName>とパスワード<password>でログインする
* ログインフォームにユーザーのログイン名<userName>を入力
* ログインフォームにユーザーのパスワード<password>を入力
* ログインボタンをクリック

Specファイルでは通常通りConceptを呼び出すのですが、その際に値を渡してあげます。
値の渡し方はSimple Parameterと変わらず、渡したい値をダブルクォーテーションで囲みます。
login.spec

## 日本ユーザーでログインする
* ユーザー"jpn_user"とパスワード"password"でログインする

## 海外ユーザーでログインする
* ユーザー"foreign_user"とパスワード"password"でログインする

SPEEDA開発でもDynamic ParametersとConceptを併用することで、よりSpecファイルのテストシナリオを仕様書のような記述になるようにしています。

Data Driven Execution

Data Driven Executionで、テーブルの値を参照する際にもDynamic Parameterを利用します。
Data Driven Executionを利用することで、同じようなStepを繰り返し記述する必要がなくなり、Specファイルの記述量をさらに減らすことができます。
例えば、下記のようなSpecファイルがあったとします。

# Simple Parameterのみを利用したログイン確認

## 日本ユーザーでログイン確認
* ユーザー"jpn_user"と"pass_jpn"でログインする

## 中国ユーザーでログイン確認
* ユーザー"chn_user"と"pass_chn"でログインする

## シンガポールユーザーでログイン確認
* ユーザー"sgp_user"と"pass_sgp"でログインする

Simple Parameterを利用してStepを再利用できていますが、全く同じようなテストシナリオが複数記述されていて冗長な感じがあります。 このようなケースではDynamic Parameterを使ってData Driven Executionにすることで、記述がスッキリします。

# Data driven executionを使ったログイン確認

     |id|userName |password|
     |--|---------|--------|
     |1 |jpn_user |pass_jpn|
     |2 |chn_user |pass_chn|
     |3 |sgp_user |pass_sgp|

## 各ユーザー毎にログイン確認
* ユーザー<userName><password>でログインする

上記の例だと、## 各ユーザー毎にログイン確認というテストシナリオが3回実施されます。
その際に、下記のテーブルで定義されているuserNamepasswordの値が行ごとに代入されて実行されます。
Data Driven Executionを使わない場合、テストシナリオの数が必要以上に多くなってしまい読む人にもストレスを与えてしまいます。
Data Driven Executionを利用した二つ目のSpecファイルの方が記述量が少なく、変数となるパラメータもテーブルにまとめられているので読みやすくなっています。

まとめ

  • ParameterでStepに値を渡すことができ、Stepの再利用性を高められる
  • ConceptとParameterを使えば、より可読性が高いテストシナリオを書くことが可能
  • Conceptに値を渡すときにDynamic Parameterを利用する
  • Dynamic Parameterを利用することで、Data Driven Executionをすることができる

Gauge正式バージョンがリリースされました!

Gaugeがβ版を終えて、正式バージョンの1.0がリリースされました!

Page top