T-DASHをREST APIのテストで使ってみた

1.はじめに

Qiitaへの初投稿です。
前々から気になっていた テスト自動化ツールの『T-DASH』 を使ってREST APIの自動テストを作ってみたいと思います。

私は普段、UIテストの自動化に取り組んでいますが、最近は新たな挑戦としてAPIテストの自動化にも手を広げました。この経験を活かして、今回はT-DASHを使ってAPIテストの実装に挑戦してみます。

2.T-DASHとは

T-DASHの公式サイトでは以下のような特徴があるようです。

• 誰でもカンタンにテスト自動化ができる時代
  • 日本語で書いたテストケースがスクリプトになる
  • すぐに使えて操作が簡単
  • 月額3,960円で開発スピードを高速化

誰でもカンタンにテスト自動化ができるというのは非常に魅力的に見えます。日本語で書いたテストケースがというのがキーになっているようなので、実際にどうなるか試してみます。

3.準備

公式サイトにある『カスタム動作を作成しよう / Pythonで作成』をみると、T-DASHで標準搭載していない機能は自分で作ることができるようです。

例:　Webアプリ操作、ファイル操作、スマホアプリ操作、DB操作、API操作などなど

PythonでやれることはすべてT-DASHで実現できるのであれば、自動テストで実現できることが想像以上にたくさんありそうです。（普段、Pythonを使ってテスト自動化を実装している私にとってはかなり期待大です。）

T-DASHの対向になるAPIは、実際にテストで使ったサイトAPIをここに公開するわけにはいかないので、テスト用のサイト httpbin.org を使います。

4.テスト実行用のPythonファイルの準備

T-DASHの『カスタム動作』を作るうえでの制約として、引数は最大３つまでというのがあります。これを念頭にテスト実行用の関数を作ってみます。

PythonのHTTPライブラリのRequestsを使ってRESTのWeb APIのリクエスト、レスポンスの取得するコードを書きます。

APITest.py

import requests

res = None
value = None

def send_request_get(url):
    global res
    res = requests.get(url)

def check_rest_status_code(status_code):
    global res
    return str(res.status_code) == str(status_code)

def get_response_value(key_list):
    global res
    global value
    value = res.json()
    for key_str in key_list:
        if key_str in value:
            value = value[key_str]
            continue
        return False
    return True
    
def check_response_value(expected_str):
    global value
    return value == expected_str

# 複数変数はデータドリブンで使用できない？対応を希望します
# def req_get(url, status_code):
#     global res
#     res = requests.get(url)
#     print(str(res.status_code) == str(status_code), res.status_code, status_code)
#     return str(res.status_code) == str(status_code)

# def req_post(url, status_code, json_item):
#     global res
#     res = requests.post(url, json=json_item)
#     print(str(res.status_code) == str(status_code), res.status_code, status_code)
#     return str(res.status_code) == str(status_code)

# def res_should_be_equal(key_list, expected_str):
#     global res
#     jsn = res.json()
#     for key_str in key_list:
#         print(key_str)
#         if key_str in jsn:
#             jsn = jsn[key_str]
#             print(jsn)
#             continue
#         print("hoge")
#         assert(False)
#     return jsn == expected_str
    

if __name__=='__main__':
    # status_code=500
    print(req_get("https://httpbin.org/status/200", 200))
    print(req_get("https://httpbin.org/json", 200))
    res_should_be_equal(["slideshow","title"],"Sample Slide Show")

5.T-DASHのカスタム動作の作成

①プロジェクトを作る

「T-DASH」を起動すると「プロジェクト一覧」が表示されます。

カスタム動作を作るには、①の「＋プロジェクトを作成」をクリックします。今回は以下の値を設定しました。

• キー： API01
• プロジェクト名： RESTAPIのテスト

上記値を入力して「作成」をクリックすると、プロジェクト一覧に追加されます。

②カスタム動作を作る

カスタム動作は、「動作定義」にある「カスタム動作」タブから作成します。

「＋新規カテゴリ作成」をクリックし、作成する動作のグループを作成します。

今回は以下の値を設定しました。（色やアイコンも変更できるようです）

• キー： API
• 動作カテゴリ： REST

上記値を入力して「作成」をクリックすると、カスタム動作の一覧に追加されます。

T-DASHのテストケース作成するときに使う以下の動作のグループを作っています。
今回はこのグループに「REST」を追加しようとしています。

作成するカスタム動作について

APITest.py	カスタム動作
def send_request_get(url):	GET送信する
def check_rest_status_code(status_code):	ステータスコードをチェックする
def get_response_value(key_list):	応答のJSONの値を取得する
def check_response_value(expected_str):	取得した値の一致を確認する

※後述するT-DASHテストケースの作成のデータドリブンの設定で利用するには、引数を１つにしなければならないようです。

カスタム動作で使用するライブラリの追加

「＋カスタム動作を追加」をクリックして、先に準備した APITest.py の4つの関数に紐づく動作を作成します。

「＋ライブラリを追加する」をクリックし、カスタム動作で使うためのライブラリを追加します。

「ライブラリ追加」の自作ライブラリにある「フォルダを開く」をクリックします。

開いたフォルダに、準備で作成した APITest.py をコピーし、フォルダを閉じます。

「ライブラリ追加」の自作ライブラリにある「再読み込み」をクリックすると、一覧に追加した「APITest.py」が追加されます。

APITest.py の右側にある「＋」をクリックし、Libraryに追加します。

Libraryの横にあるテキストボックスに「String」を入力し「＋」ボタンをクリックします。

※３つ目の関数 def get_response_value(key_list): の引数で渡すリストを作るための、RobotFrameworkライブラリです。

「閉じる」をクリックします

これで、カスタム動作を作るためのライブラリの準備が完了しました。「動作関数作成」画面の「＋ライブラリを追加する」の横に APITest.py と String が表示されていれば成功です。

カスタム動作の作成

動作名などの必要な情報の入力と、RobotFrameworkによるプログラミングを行います。

フィールド	値	説明
動作名	GET送信する	ここで使う動作の名前を設定します。
利用変数	画面定義を使用を選択	「通常の変数として使用」を選択すると、後述するデータドリブンの設定が使えないようでしたので、「画面定義を使用」を選択します
利用変数	設定値	利用する変数を選択します。設定値のみデータドリブンで設定できるようです。
フォーマット	URL「設定値」にGETでREST送信する	利用変数で選択すると「設定値」がテキストボックスに設定されるので、それを利用して文章を作ります。※埋め込み変数として使うようです。
動作種類	操作	何に使うかわかりませんでしたが、動作の分類っぽいので操作を選択します

RobotFrameworkのコードを以下のように作成します。

${value}の変数に入力した値が格納されますので、それを利用したコードにします。
APTTest.py の関数を使います。大文字・小文字の区別はなく、_（アンダースコア）については、空白で良いみたいです。

「保存する」をクリックします。

残りの３つも同様に作成します。

ステータスコードをチェックする

応答のJSONの値を取得する

取得した値の一致を確認する

6.T-DASHのテストケースの作成

作成したカスタム動作を使うT-DASHのテストケースを作成します。

6-1.ステータスコードを確認するテストを作る

左のメニューにある「テストスイート」から「テストスイートを作成する」をクリックします。

テストスイート名を入力して「作成」をクリックします。今回は「APIのテスト」と入力しました。

「テストケースを作成する」をクリックします。

テストケース名を入力して「作成」をクリックします。今回は「GETステータスコードのチェックテスト」と入力しました。

作成したテストケースをクリックします。

先ほど作成したカスタム動作「REST」が動作カテゴリにあるので、それをクリックします。

※作成した4つの動作もあります。

再掲：
T-DASHの対向になるAPIは、実際にテストで使ったサイトAPIをここに公開するわけにはいかないので、テスト用のサイト httpbin.org を使います。

このテストでは以下のREST APIを使用します。最後の200の数字がステータスコードで使用されます。
https://httpbin.org/status/200

動作にある「GET送信する」をクリックします。「設定値（設定値３）」が入力できるようになるので、そのセルに「https://httpbin.org/status/200」を入力します。

2行目を選択します（どのセルでも良いので動作を作成する行をクリックします）
動作にある「ステータスコードをチェックする」をクリックします。「設定値（設定値３）」が入力できるようになるので、そのセルに「200」を入力します。「保存する」をクリックします。

6-2.レスポンスのJSONの値を確認するテストを作る

テストケースのところにある「＋」をクリックします。

テストケース名を入力して「作成」をクリックします。今回は「GET応答のJSON値のチェックテスト」と入力しました。

作成したテストケースをクリックします。

先ほど作成したカスタム動作「REST」が動作カテゴリにあるので、それをクリックします。

※作成した4つの動作もあります。

このテストでは以下のREST APIを使用します。
https://httpbin.org/json

実行すると以下のjson値が返ってきます。

レスポンス

{
  'slideshow': {
    'author': 'Yours Truly', 
    'date': 'date of publication', 
    'slides': [
      {
        'title': 'Wake up to WonderWidgets!', 
        'type': 'all'
      },
      {'items': [
        'Why <em>WonderWidgets</em> are great',
        'Who <em>buys</em> WonderWidgets'
        ],
        'title': 'Overview',
        'type': 'all'
      }
    ],
    'title': 'Sample Slide Show'
  }
}

以下のように入力し、保存をクリックします。

動作	画面名（設定値1）	要素名（設定値2）	設定値（設定値3）
GET送信する			https://httpbin.org/json
ステータスコードをチェックする			200
応答のJSON値を取得する			slideshow,author
取得した値の一致を確認する			Yours Truly

6-3.テストを実行する

6-2までで作ったテストケースを実行します。

「選択したテストを実行する」をクリックします。

テストが完了したら「テストレポート」を開くをクリックします。

レポートが表示されます。

最低限の情報だけのシンプルなレポートです。必要な情報は揃っているので十分だと思います。

7.データドリブンの設定

7-1.テストのバリエーションを増やす

今作ったテストケースのバリエーションを増やします。バリエーションを増やすのもとても簡単に設定できたので紹介します。

「テストスイート」画面のテストケースにある「データドリブンアイコン」をクリックします。

データドリブン対象で、データを入れ替えてテストしたい手順にチェックを入れ、「データドリブン入力値設定」をクリックします。

スプレッドシートが表示されるので、マウスで右クリックし「下に行を挿入」をクリックします。
（後で気づいたのですが、エンターキーを押すだけで行が簡単に追加できました）

以下のように３パターン追加し、「保存」をクリックします。

	GETステータスコードのチェックテスト.8-GET送信する	GETステータスコードのチェックテスト.9-ステータスコードをチェックする
1	https://httpbin.org/status/200	200
2	https://httpbin.org/status/300	300
3	https://httpbin.org/status/500	999

※3行目のパターンは、あえて失敗するように設定してみます。
※8-、9-などの数字は何を指しているかわかりませんが、T-DASHが勝手に付与した値なのでしょうか。特に気にせず進めます。

閉じなかったので、「閉じる」をクリックします。

テストケースの「データドリブンアイコン」に「3」のバッジが付きます。データドリブンのテスト実行数を表しているようです。

7-2.テストを実行する

7-1までで作ったテストケースを実行します。

「選択したテストを実行する」をクリックします。

1件失敗しますが、ここではどこの手順で失敗したかまではわからないようです。

テストレポートを開くをクリックします。

「ステータスコードが「999」であること」が失敗アイコンがついているので、その手順で失敗したと判断できます。
「ステータスが一致しません（999）」は、カスタム動作で定義したメッセージです。

※終了処理のところに、「ブラウザが見つかりません」のエラーが表示されています。そもそもこのテストでブラウザは使っていないのに何故だろう？と思いましたが、ブラウザテストを想定して強制的に実行しているのではと想像します。そうだとしても、このメッセージは見せなくてよいのでは？と思いました。

8.T-DASHの良い点、悪い点

8-1.T-DASHの良い点

• 自動テストの構築は、公式サイトにある通り誰でもできると思います。
  • 開発できない同僚も半日でブラウザ操作の自動化をできるようになっていたのは驚きでした。ツールの使い方を教えなくとも、自分で使えるようになっていたので学習コストは本当に低いツールだと思います。
• カスタム動作は、誰でもというわけにはいきませんが、エンジニアを飽きさせない上手い仕掛けだと思います。実際にPythonとRobotFrameworkで実現できるものであれば、何でも自動化できるのではないかと思います。
  • 公式サイトのチュートリアルをみながら作ることはできました。
  • 作成したカスタム動作はエクスポートできるので、誰か一人が作って動作を配布すれば、誰でも難しいテストも自動化できそうです。
  • T-DASHはRobotFrameworkとの親和性も高いので、抱負にあるテスト用ライブラリを使用できると考えると、自動テストできる対象はかなり増えそうです（Pythonも使えるので、T-DASHで自動化できないシステムは殆どないのではないかと思います）
• テストオペレーションが同じでインプット、アウトプットのパターンが異なるだけのテストが簡単に実現できた。
  • データドリブンの設定はとても便利だと感じました。
  • 網羅的にテストをするためのバリエーションを増やすのがとても簡単でした。
• 過去のT-DASH記事をみましたが、そこにあった改善点については、対応されているようでした。
  • ユーザーの声をツールに反映しているのは非常に好感が持てます。

8-2.T-DASHの悪い点

悪いというわけではありませんが、躓いた点や使いにくいと感じた点について書きます。

• SetupやTeardownを設定できない？
  • 前準備や後処理を組み込むところがなさそう。今回は使用しませんでしたが、前処理でAPIの認証情報をとってくるなどを実行したいと思いました。いまのツールでは、不要なテストケースを作成、不要なテスト実施の成功カウントも増えるため、不便だと感じました。
  • テストスイートやテストケース単位で前準備、後処理を作ることができると、とても柔軟なテストが実行できると感じました。
• カスタム動作の確認をカスタム動作をつくりながら実行できない
  • カスタム動作を作る⇔テストスイート画面でテスト実行するを何度も行ったり来たりが煩わしいと感じました
  • カスタム動作の自作ライブラリで失敗したときの、原因を見つけるのにレポートの右上にあるLOGをクリックして確認しないといけない。これに気づくのに時間がかかりました。
  • 引数にリストを渡せないなどの制限事項について、どう対応したらいいか最初は全くわからなかった。このようなコツをチュートリアルやTipsのようなページがあると良いと感じました。
• カスタム動作を作るときの導線が気持ち悪い
  • チュートリアル通りに進めれば実装はできるのですが、ライブラリの追加、フォーマット、動作名など、下から上に入力が進む感じで気持ち悪いと感じました
• データドリブンが設定できない
  • 変数が３つないと使えなさそうです。今回の記事で作ったテストで言うと、一つ目の変数と２つ目の変数をデータドリブンで設定したかったのですが、設定できなかったです。ひとつの手順で、全ての値（第一～第三引数）に対してデータドリブン対象にするかどうかで複数選択できると使うシーンが増えると感じました。
• ブラウザを使っていないテストが失敗したときのSeleniumのエラー
  • 今回のようにAPIのテストだけの場合でも、テストが失敗すると、「ブラウザが見つかりません。ブラウザを開く動作を実行しておく必要があります」のエラーがレポートに出力されている。
  • Setup、Teardownの設定ができれば解決する問題かと感じます。
• UIの色のメリハリがあるといいと思います
  • プレースホルダなのか、表示ラベルなのか同じ色のグレー文字で区別がつきにくく、あちこちクリックしちゃいました。

9.さいごに

有料のツールははじめてではありませんが、これだけ使えて3,960円はかなりオトクだと思います。開発スキルがあれば、自動化の可能性は無限大だというのが、個人的に面白いと思います。

コンセプトを維持しつつ、ユーザーの声を反映している良いツールだと思うので、今後のアップデートにも期待大です。