はじめに

はじめまして、SHIFTで自動化アーキテクトをやっている片山 嘉誉です。

既にnoteでは”Katayama Yuta”さんがたくさんの記事を書かれていて、同じ「Katayama」では被ってしまうため、私は漢字で投稿して行きたいと思います！

SHIFTではテストの自動化を行う際に「Racine(ラシーヌ)」という、SHIFTの独自ツールを使用して環境構築することが多いのですが、 ”自動化” といってもどういうことをするのか良く分からないという方も多いと思います。

また、いざ自動化環境を作っても開発が続く限りそれをメンテナンスしなければならないのですが、自動化導入後は開発側でテストスクリプトをメンテナンスされることも多いため、この記事ではそのイメージを共有できればと思っています。

Racine(ラシーヌ)とは

まずは今回使用するRacineについて説明したいと思いますが、RacineはSHIFTが独自に開発したJava言語で実装を行う自動テストのフレームワークです。Javaで実装するためGitなどのバージョン管理システム（VCS）でテストスクリプトを管理することができるのも特徴のひとつです。

ベースとなっている技術はWebブラウザを操作する ”Selenium” と、スマートフォンなどのアプリを操作する ”Appium” になるのですが、それらを使いやすく拡張したものがRacineのフレームワークだと思ってもらうのが良いと思います。

テストの実行はJavaのテストフレームワークである ”JUnit” の仕組みで実行され、テスト結果の出力はHTMLでレポートを作成する ”Allure” が使われています。

もしJUnitを使ったことがある方であれば、テストを作る際に使用するAPIがRacineが提供するAPIに置き換わる、っと思って頂ければ分かりやすいかと思います。

JUnitを使ったことは無いけどSelenium（Selenide）やAppiumなら使ったことがある、という方であればJUnitの仕組みを少し覚えるだけで、Selenium（Selenide）やAppiumを使いやすくしたRacineのAPIでテストスクリプトが書けると思います。

そして、何一つ分からない、という方は自動化環境導入時にSHIFTから 「自動テストスクリプト作成ガイド」 もございますので、それを参照いただきながら学習を進めていただければ、テストスクリプトの作成も行えるようになると思います。

テスト実装の構成について

今回はWebアプリの自動化に焦点を当てて説明しますが、Webアプリのテストの実装は”ページオブジェクトモデル（POM）”が使われています。

ページオブジェクトモデルについて簡単に説明すると、各画面（ページ）毎に処理（クラス）を分け、画面内の操作（メソッド）を画面毎に実装していく、というイメージです。

ページオブジェクトを使用することによりテストのシナリオとは別に画面内の操作を記述することができるため、処理の再利用性、保守性（メンテナンス性）、並びにテストスクリプトの可読性が上がります。

例えばログインを行うという処理を全てのテストスクリプトに実装するのではなく、ページオブジェクト側にテストスクリプトとは分けて実装することで同じ処理を繰り返し使用することができますし、ログイン画面が改変された際はページオブジェクト側だけ直せばテストスクリプトは直さなくて良くなります。

但し、ページオブジェクトモデルは良いところばかりではありません。

というのも、画面（ページ）毎にクラスを設計し、画面内の処理をクラス内のメソッドとして実装するということは、テスト対象となるWebアプリの構成を考えながら実装を行わなければ成らないため、導入時のコストが高くなります。

実装をサポートするツールについて

そのような導入時のコストを抑えるため、Racineではブラウザの操作からテストスクリプト、並びにページオブジェクトを自動で作成するという機能を用意しています。

テスト対象となるWebサイトをブラウザで操作し、その記録をRacineで変換できるようにJavaファイルとして出力、出力されたJavaファイルをRacine上で変換すれば操作手順となるテストスクリプトと各画面内の処理となるページオブジェクトが自動で（Javaのソースコードとして）生成されるという流れです。

この機能を使うことで検討に時間が掛かるページオブジェクトの設計や実装を簡略化でき、自動化環境の導入コストを抑えることができます。

但し、自動生成したものがそのまま使えるという訳では無いため、シナリオ毎に自動化するため処理順を見直したり、適宜シナリオに合わせて期待値との確認処理（アサーション）を追加する必要があります。

改修箇所について

ではどのようなメンテナンスが必要になってくるかについてですが、ページオブジェクトモデルの説明で大体予想が付いているのではないかと思ったりしています。

まず画面の操作手順が変わった場合はテストスクリプトの修正が必要になります。

例えばログイン時に２段階認証を行う改修が入った場合、その２段階認証を行う手順をシナリオに追加しなければなりません。

また、その２段階認証の操作を行うためのページオブジェクトの実装も必要となってきます。

その他にも、アプリ側の表示に使用しているUI部品に変更が入った場合、それを参照して値を取得するという処理も変更する必要があるため、ページオブジェクトの修正が必要です。

このように、テストの実装はアプリの実装と対をなすように連動して修正が必要であるため、修正を怠ると自動テストが動かなくなる、ということが発生してしまいます。

また、大きな改修が入った際はテストスクリプトをはじめから作り直した方が早い、という場合もあり、せっかく作った自動化環境が無駄になってしまうこともあります。

そのため、どこを自動化してどこを自動化しないか、という線引きをきちんと設け、必要以上に自動化に頼らないということも必要な考えであると思います。

おわりに

今回はWebアプリに焦点を当てて説明を行いましたが、モバイルアプリに関しても共通処理を部品化してシナリオと分離して管理するという考え方は同じになり、メンテナンスも同じように発生します。

RacineではAppiumの実装をSelenideっぽく書くAPIが用意されており、Webアプリの自動化ができればモバイルアプリの自動化に掛かる学習コストが抑えられるようになっています。

世の中に存在する自動化ツールはツール毎に覚えることがたくさんありますが、RacineはSelenium（Selenide）やAppiumといった一般的なツールをベースにJUnitを使ってJavaで実装できるため、Racine特有の知識というものはそれほど多くありません。

Javaが使える（最悪オブジェクト指向が分かる）という方からすれば、そこまで学習コストは高くないと思います。

また、覚えたSelenium（Selenide）やAppiumの知識も無駄になることは無いと思うので、自動化に興味をお持ちの方はぜひ、SHIFTのRacineの使用をご検討ください。

それではまた次の記事でお会いしましょう！

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/