【T-DASH】コードレスでここまでできる！T-DASHでスマホアプリの自動テストを実践

# 導入
こんにちは、もんすんです。

Advent Calendar 2024の[今年もT-DASHを使ってみた！ by T-DASH Advent Calendar 2024](https://qiita.com/advent-calendar/2024/t-dash01)の10日目の記事をお届けします！

これまで私は、スマホアプリエンジニアとして、`Unit Test` / `Widget Test` / `Integration Test`といったテストコードをきちんと書いてテストを実行することはありました。
実際に現在の業務でも同様にテストコードは書くルールになっています。

しかし、実機やシミュレータを使った動作検証は打鍵で行うことが多く、何かいいツールはないものかと常々感じていました。

色々調べてみると、スマホアプリの自動テストとして`Appium`というツールがあることを知りました。

https://appium.io/docs/en/latest/

`Appium`は、モバイルアプリケーションの自動テストを行うためのオープンソースツールです。
Seleniumと同様な感覚で、テストスクリプトを作成して、実機およびエミュレータを利用してテストすることができます。

しかし、、、

<font color="red">**テストコードを書くのがしんどい！！**</font>

んですよね。

何か他にテストコードを書かなくてよいツールはないか調べていたところ、`T-DASH`に辿り着きました。
今回は`T-DASH`でのテスト自動化を試してみた体験を共有します。

:::note info
会社の資産を使うことはできないので、個人的に開発しているスマホアプリに対して`T-DASH`を利用してみました。
:::

# T-DASHについて

`T-DASH`は、**バルテス株式会社**が提供するテスト自動化ツールです。
コードレスでテストを自動化できる点で注目を集めています。

特にモバイルアプリの開発・テストを業務でも個人でも行う私にとって、その有用性や課題を探る良い機会となりました。

## 概要

https://service.valtes.co.jp/t-dash/

`T-DASH`は、バルテス株式会社が提供するクラウド型テスト管理ツールです。

テスト管理に関するさまざまな情報を**一元管理**でき、それをGUIで**簡単に**確認できます。
これにより、チーム間での情報共有がスムーズに行えるようになり、プロジェクト進行に合わせて柔軟に対応が可能です。

さらに、日本語で書いたテストケースがスクリプトになるということも謳っており、初心者・初学者にもハードルが低い設計になっていることも、利点に感じます。

:::note info
**ソースコードベースのテスト**では、ソースだけでなく、ドキュメント化などの管理が必要になります。

この場合、ソースコードの変更がドキュメントに反映されないと、内容が古くなり、実際の仕様と乖離が生じることがあります。
また、コードとドキュメントを常に更新する必要があり、開発者の負担が増えてしまいます。
ドキュメントが更新されていない場合、信頼できる情報源が不明確になり、誤解やバグの原因となることもあります。
:::

## 料金

https://service.valtes.co.jp/t-dash/pricing

`T-DASH`には、初めての導入をサポートするトライアル期間も提供されています。
私も今回は、トライアル期間で使い倒してみようと考えています。

プランは3つ用意されており、最も最安で運用する場合、1ライセンスで、

- 月額4,840円

で、利用することができるとのことでした。

## T-DASHの魅力

具体的な体験談に入る前に、`T-DASH`の特筆すべき魅力をご紹介します。

1. **導入の容易さ** 🖥️  
   他のテストツールと比較して、インストールや初期設定が非常にシンプルです。  
   初めはMacに導入しましたが、スマホアプリのテストは現在Windowsのみ対応のため、Windowsに再インストールしました。それでも環境構築に詰まることはなく、スムーズに進められました🎉
2. **コストパフォーマンス** 💸
   無料トライアル期間を利用しましたが、コストは非常に抑えられていると感じました。実際のコスパについては継続利用しないと評価が難しい部分もありますが、それでも魅力的な価格設定だと思います。
3. **ユーザー目線の設計** :eye:
   私のチームには、プロダクションコードの開発に集中したいと感じているエンジニアが多くいます。`T-DASH`は、そうしたニーズに応える使いやすさと実用性を両立しています。また、日本語対応の直感的なUI/UXは、効率的に自動テストを進めるための強力なツールと感じました。

# T-DASH体験

## テスト対象のアプリと環境

テスト対象のアプリは、私が個人で開発している単語帳アプリです。
諸事情あって、日本語の単語帳になっていますが、その辺りの詳細は割愛します。

アプリ自体は、Flutterで開発しており、今回はAndroid用のAPKファイルを作成し、テスト実行しました。

### 環境

- Windows 10
- Androidシミュレータ: Pixel 9 Pro XL
	- Android 14

## テスト準備の流れ
まずテストを実施するためのテストケースを作成していきます。
[こちら](https://service.valtes.co.jp/t-dash/function/tutorial/mobileapp_beta_vol_003)を参考にしました。

### 1. T-DASHの起動とプロジェクト作成
インストールした`T-DASH`アイコンをダブルクリックすると、`T-DASH`がバックグラウンドで起動し、自動的にChromeのタブが新しく開かれました。(ポートは8686がデフォルトのようでした。)

画面の指示に従って、プロジェクトを作成しました。

![2024-12-03_11h15_27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/c8b0eee5-07c4-972c-af95-5c67c40a8159.png)

### 2. AppiumとAppium Inspectorの起動

以下のコマンドを叩いて、Appiumを起動します。
Appiumを起動しておくことで、`T-DASH`がスマホ実機、もしくはシミュレータ上でスマホアプリを操作可能になります。

```bash
appium --allow-insecure chromedriver_autodownload
```

特にAppiumに問題がなければ、以下のようにコマンドプロンプト上に特にエラーが出ることなく、Appiumが起動します。

![2024-12-03_11h11_06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/b5b992e1-d87a-42f9-8eb0-02e802497c76.png)

さらにAppium Inspectorをアプリケーションアイコンから起動します。
こちらのAppium Inspectorは、スマホアプリの画面の要素を抽出するのに利用します。

![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/9549b17a-0a60-8668-efca-cf575eb1d236.png)

Appium Inspectorはテスト実行時には不要ですが、テストケースの準備には必須のものになります。

:::note warn
正確には「必須」ではありません。
画面要素を別の方法で取得できるのであれば、Appium Inspectorは不要です。
:::

### 3. Androidシミュレータ起動

次にテストで使用するAndroidシミュレータを起動します。
Android Studioを開きます。
プロジェクトを選択する画面で「…」をクリックし、`Virtual Device Manager`から使用したいデバイスを選択して起動します。

![画像2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/7aab892a-6de8-f15e-0331-82795ef34518.png)

今回は、Pixel 9 Pro XLを選択しました。
![2024-12-05_22h27_45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/a0cf778b-e148-46e8-bd42-fe7d4429651e.png)

### 4. T-dashで画面要素取得準備
次は、`T-DASH`の画面で、「画面要素取得の準備」を行います。
以下の画像のように「画面定義」を選択し、画面名を入力します。今回は1画面「WordListScreen」という画面を定義しました。

ここで、黄緑の線の部分には何の要素も定義されていない空の状態です。

![2024-12-03_11h16_30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/0c98574c-9dc0-adb9-82cf-c50c4933ffc4.png)

ここからAppium Inspectorで取得した値を追加していきます。
「端末を選択し、画面要素を取得」を押し、表示されたモーダルの一番下の「端末接続情報をコピーしてAppium Inspectorを起動」をクリックします。

![画像3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/546ad4c2-5a48-7a13-e23a-a165ecd70539.png)

### 5. シミュレータ上でアプリを起動
直前の画像の記載されている手順を参考に取得したJSONをAppium Inspectorに貼り付けます。
保存ができたら、「Start Session」を押すと、晴れて以下のようにシミュレータでアプリが起動し、Appium Inspectorで画面要素を取得できるようになりました。

![2024-12-03_11h20_09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/638d4d25-3a09-49bd-adca-22c8cfb7a672.png)

上記画像の左側がシミュレータ、右側がAppium Inspectorになります。

### 6. 画面要素の取得

ここからは直感的に操作ができ、気楽に自由に操作することができます。

![2024-12-03_11h21_22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/1661e0c9-8d50-b480-0142-1f178427c398.png)

① Appium Inspectorで取得したい画面要素をクリックします。
② 右側に出てくる`xpath`をコピー。クリックするだけで、コピーされます。
③ T-DASHの画面要素の「値」にコピーした`xpath`を貼り付けて、「要素名」を自由に設定します。

以上です！
必要な画面要素分、この作業を繰り返すだけで、画面要素を取得することができます。

#### 画面要素取得後
今回はこんな感じに画面要素を取得しました。
画面要素名は、今回は適当につけました。
ですが、通常のプロジェクトでは、命名ルールなどを設ければ、特にチーム内の齟齬は発生させることなく、運用ができると思います！

![画像4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/736d45b0-475f-8b25-4ab8-434b7b9e7fb9.png)


### 7. テストシナリオ作成

次に左ペインから「テストスイート」を選びます。
ここでは、テストスイート・テストシナリオを作成していきます。
以下の画像では、すでに「WordListScreenシナリオ」というテストスイートを作成済みですが、画面の指示通りに操作するだけで、ここは特に躓くことはないと思います。

また、新たに作成する場合は、「+」ボタンから追加が可能です。

![画像5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/bdc58855-1929-784d-c0a4-569ec1512f08.png)

さらに右側のエリアでは、テストケースを作成していきます。
テストスイートと同じく「+」ボタンからテストケースを作成することができます。

テストケースの具体的な処理に関しては、さらに各テストケースのタイトル(上画像の「単語詳細ボトムビュー表示」の部分)から設定していく仕組みになっていました。

テストケースの作成は、以下のような画面になります。
![画像6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/77aea0f2-cd9a-a0e4-171b-bbb11327b15a.png)

<font color="red">テストケースの作成がとても簡単</font>なのが、本当に魅力的です。

上の画像にあるように左(紫の枠)に定められた「動作」があります。
これには、スマホアプリであれば、**タップ**・**スワイプ**といったものまで含まれます。
この「動作」をクリックすると、右のエリアの「動作」(黄緑の枠)にその動作が追加されます。

たったこれだけで、テストが作れるわけです。

「動作」によっては、**「どこをタップするか」** などの指定が必要なので、上の画像における赤枠のところに、[6. 画面要素の取得]で取得した画面要素などを設定していきます。

繰り返しになりますが、この操作だけでテストケースが作成できることが<font color="red">とても簡単</font>で良いです。

:::note info
**【他の方からの声】**

この辺りのデモンストレーションを会社のチームに共有しました。
そのときは、この画面の操作容易性に関して一番盛り上がっていました。
**プロダクションコードを書きたいエンジニアメンバーからは、とても嬉しい**という声も聞くことができました。
:::

## テスト実行

さて、テストを実行していきます。
この辺りの操作も、画面に従えば容易なので、操作の説明は割愛します。

![テスト実行.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/bae9f58b-21c8-9b4c-94f2-7f067939529d.gif)

うーん、テストとしては失敗してしまいました。が、まぁ記事としては良かったかもしれません。

### テスト結果

NGになるとこのような感じで、どこで失敗したか、とその際のスクリーンショットがレポートとして残るようです。

![テスト結果_失敗.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/2a69a43b-7bbf-f149-0531-057edc3d564e.png)

今回はアプリの起動時間が結構かかったみたいで、テストケースの判定に画面表示処理が間に合わなかったみたいです。

### (おまけ)全てOKだった場合

結構シンプルですが、OKであれば全体的にグリーンになり、スクショなども特にないようでした。

![画像8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/d2a56da0-5909-84e5-0f9e-2dcf289f56c6.png)

### (おまけ)テストケースをDLしてみた

テストケースはエクセルファイルとして出力できるので、ダウンロードしてみました。

![画像9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/ac05dfb3-86b2-28b0-529c-31c6c7839f6b.png)

試してはいませんが、逆にテストケースのインポートもできるみたいでした。

https://service.valtes.co.jp/t-dash/function/tutorial/testscenarios_test_cases_vol_006

## テスト実行してみた感想

### 良さそうな点

:::note info
1. **シナリオ作成の手軽さ**
    上述しましたが、シナリオ作成画面において、左側の選択項目から操作項目を選べるため、シナリオ作成が非常に簡単でした。(下画像の紫の枠)
    特に初心者にも使いやすく、コードレスの恩恵を実感しました。
![画像10.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1655179/5c78d60e-658a-538e-76cd-cda07de4ebd3.png)

    
2. **画面要素の可視化**
    テストシナリオ作成時に、設定した画面要素が`T-DASH`内の左下に表示される仕様は分かりやすかったです。(上画像の赤の枠)
    どの要素に対して操作を行うのかが一目で分かりました。
    
3. **Appiumとの連携**
    AppiumやAppium Inspectorを活用してスマホアプリの自動テストを実行できるのは大きな魅力でした。
    従来の打鍵テストから大幅に効率化できる点が特に良かったです。
    
4. **通知バーの操作などの対応**
    通知バーの操作やバックグラウンドからフォアグラウンドに切り替わる処理もシナリオに組み込めるみたいでした。これらの機能が新鮮で、ユニークな使い道が広がりそうだと感じました。
:::

### もうちょっと...な点

:::note warn

1. **タップできない要素への対応**
    Appium Inspectorの仕様かもしれませんが、一部タップできない要素があり、その場合は座標指定で操作を行う必要がありました。
    これがもう少し直感的に改善されると良いと感じます。
    
2. **GUI操作の制限**
    GUIで操作が完結する点は魅力的ですが、複雑なシナリオや特殊な要件では柔軟性がやや不足している印象でした。
    
3. **Windows限定の対応**
    モバイルアプリのテストは現状Windowsのみ対応で、Macユーザーには制約があります。
    今後、対応環境が広がるとさらに使いやすくなりそうです。
:::

# 最後に

今回、初めて`T-DASH`を使用してモバイルアプリのテスト自動化を試してみました。
コードレスで直感的に操作ができる点や、Appiumとの連携による柔軟なテストケース作成は、とても魅力的でした。

対応環境や柔軟性における課題は、`T-DASH`の将来的なアップデートや拡張によって解決されることを願っています。

これからも`T-DASH`を活用し、業務にも適用していけたらと思います。
そして、同じように「テストコードを書くのがしんどい」と感じている方にとって、この記事が少しでも役立つ情報になれば嬉しいです。

最後まで読んでいただき、ありがとうございました！😊

## 参考

https://service.valtes.co.jp/t-dash/function/tutorial/mobileapp_beta_vol_001

https://service.valtes.co.jp/t-dash/function/tutorial/mobileapp_beta_vol_002

https://service.valtes.co.jp/t-dash/function/tutorial/mobileapp_beta_vol_007