mablでOutSystemsのUIテストを試してみる

mablはローコードでE2Eテストをかけるサービス。
14日間トライアルで試せるので、OutSystemsで作ったアプリケーションに対するテストを試しに作ってみる。
今回は、非常に簡単な（Entityのドラッグ＆ドロップで作れるもの）アプリケーションを対象とする。

環境情報

Personal Environment(Version 11.21.0 (Build 39357))
Service Studio(Version 11.54.18)

mabl

デスクトップツールのHelp->Aboutで確認すると

• mabl app version: 1.33.5
• Test runner version: 2.1.58.2

サンプルアプリケーションの準備

1. 空のReactive Web Appを作る
2. mablUser Role (一般ユーザー想定）を作成
3. Service Studioに付属のTasks.xlsxをインポート
4. 出来上がったTask Entityをドラッグ＆ドロップで画面作成
5. 一覧画面はmablUserだけ権限付与

出来上がったアプリケーションはこんな感じ。

mabl側の準備

mablのトライアルを開始しておく（公式サイト右上のボタンから申し込み）。
mablのデスクトップツールをインストールしてログインしておく。

Browser Testを作ってみる

細かい手順は、デスクトップツールをインストールすると最初に表示されるチュートリアルでわかるので、以下ポイントをざっくり見ていきたい。

ブラウザテスト作成時の幅に注意する

mablでOutSystems向けテストを作るにあたっては「幅」の値に気を付ける必要がありそう。
window.innerWidth || document.documentElement.clientWidthの値が1024以下だとタブレット、更に700以下だとスマートフォン用の見た目になってしまうので。この判定ロジックはOutSystemsアプリケーションをブラウザで開き、開発者ツールでソースコードを文字列「1024」で検索すると見つかる。

ブラウザテスト作成時にウィンドウの幅を指定できるが、1024 + α（ブラウザの境界部分の幅など）以上で指定しておく必要がある。

以下は幅を「1024」にしたときの、それぞれの値（開発者ツールのコンソールタブで確認）。この設定だとタブレット向け表示になってしまうため、もっと大きな値を設定する必要がある。

window.innerWidth
1008
document.documentElement.clientWidth
1008

私の手元では、幅を「1041」以上にすれば、デスクトップ向けの表示でテストを作成・実行できた。

複数のモニタ利用時の注意

私は複数のモニタを使っていて、片方のモニタはSurfaceでちょっと解像度が低い。
Trainer（テストを実アプリケーションの操作から作成するためのウィンドウ）起動時に解像度が低い方のモニタで記録が始まってしまうと、アプリケーションを表示するウィンドウの幅を、「モニタの解像度幅 - Trainerウィンドウの幅」に自動調整してし、結果としてタブレット用表示になってしまう現象があった。

このときは、アプリケーションウィンドウを、Trainerウィンドウが表示される前に大きなモニタに移動させることで解消した。今回はお試し程度だからよいが、本格的にテスト作成するときは、最初から大きなモニタを使いたいところ。

セレクタの確認

E2Eテストの場合、操作・Assert対象要素を指定するセレクタが問題になることが多いと思う。
特にOutSystemsの場合、idを確実に指定することができない（WidgetのNameに設定した値は、idに後方一致するが）こともあり、どのようなセレクタ指定が行われるかは気になるところ。

以下は、Paginationの総件数部分をTrainerからクリックして指定したときの、UI。
対象DOM要素の様々な属性とその値を収集したうえで、最もAssertに向いていそうなものをデフォルト選択しているようにみえる。

シナリオ：一般ユーザーでログインし一覧画面のデータ数をチェック

以下のシナリオでテストを作成してみた。

1. アプリケーションにアクセス⇒未ログインなので、ログイン画面に自動遷移
2. 一般ユーザーでログイン
3. 一覧画面に遷移するので、テーブルのデータ数をPaginationから取得して確認（5）
4. 一覧画面上で、キーワード「f」でフィルタリング
5. 一覧画面上で、テーブルのデータ数をPaginationから取得して確認（2）
6. ログアウト
7. ログイン画面に戻っていることを確認

テスト対象アプリケーションに対する操作が、自動的にTrainerウィンドウに記録されるので、記録内容の微修正を行うだけで、作成できた。

作成したテストを保存すると以下のように、各ステップがコマンドとそれに対するパラメータの形式で記録されているのがわかる。

テストの実行について

デスクトップツールを利用して行うローカルテストもあるが、おそらくテストの開発用。
運用にはクラウド実行を使う。
これは、mabl内のリソースで実行される。
実行過程の情報はステップごとに

• スクリーンショット
• 詳細なログ（そのステップのコマンドと結果。何が出るかはコマンドの種類によって違うようだ）

が自動記録される。
上にあるような短いシナリオ1つでも1分ほどかかる。やはりE2Eテストでしかもクラウド環境内のものなので時間はかかるようだ。

気になる点

モバイルアプリケーションを対象とするテストは作成できない

現（2023/07/29）時点では、テスト対象となるのはWebアプリケーションのみ。
OutSystemsではモバイルアプリケーションも作れるが、そちらはテストできないということ。
FAQ　より

Mabl only supports web-based applications today, but we can test responsive mobile websites

mablをやめるとき、作成したテストはどうなるか

OutSystemsは、独自のヴィジュアルな方法でプログラムを作成するが、契約をやめるときにC#のソースコードをエクスポートできる。
これと同等のことが、ローコードのテストツールでmablでもできるかは気になるところ。

Pricingのページによると、最上位のEnterprise PlanならSeleniumへのExport機能があるようだ。これが使えるなら、OutSystemsのアプリケーションと同じく、動作させ続けることは可能なのかもしれない。

Exporting browser testsによると、Selenium IDEとPlaywright形式でのエクスポートが可能であるとのこと。今は確認する時間が無いが、もしmablを実際にプロジェクトで使う機会があれば、確認して起きたところ。

感想

シナリオ作成者に必要そうなスキルとしては、テスターとしての基本知識・スキルの他に

• HTMLタグ・CSSのスタイルの知識
• 操作はコマンド＋コマンド毎に決まったパラメータという形であらわされていそう⇒OSのCUIで操作したりシェルスクリプト書けるとか or 基礎的なプログラミング能力　があればよさそう

くらいだろうか。
ローコードだけあって、コードベースのテストツールよりは必要な知識は少なくて済みそう。
同じくローコードなので、ツールが提供する機能や仕組みを踏まえれば高速でも、そこを外れると生産性が落ちたり、そもそも作れないという可能性もある。