More than 5 years have passed since last update.

【SAPUI5】チュートリアルを見ながらTest Driven Developmentを体験する (3) OPA5

Last updated at 2019-04-20Posted at 2019-04-17

OPA5テストの歩き方

OPA5テストは、ユーザの操作に関係する機能のテストで使用します。（以下、OPA5のことをOPAと呼びます）
今回は以下のチュートリアルを参照しながら、OPAテストの流れ、考え方について紹介します。
Step 6: A First OPA Test
Step 7: Changing the Table to a Growing Table

「チュートリアルを見ながらTest Driven Developmentを体験する」シリーズの目次はこちら

OPAテストは「話すように書く」

OPAのテストケースはUser Journey、すなわちユーザが何を見て、どう操作するかを説明するように書きます。
以下はこれから実装するテストのコードですが、メソッド名に注目してください。
iPressOnMoreData: "MoreData"を押す
theTableShouldHaveAllEntries: テーブルにすべてのエントリが表示される
iTeardownMyApp: アプリを終了する
ユーザの操作とその結果の説明になっています。

	opaTest("Should be able to load more items", function (Given, When, Then) {
		//Actions
		When.onTheWorklistPage.iPressOnMoreData();

		// Assertions
		Then.onTheWorklistPage.theTableShouldHaveAllEntries();

		// Cleanup
		Then.iTeardownMyApp();

opaTestファンクションには3つの引数が渡されています。引数はそれぞれ以下の意味を持っています。

Given ：与えられた条件（前提）　例）アプリを開く
When ：～という操作をしたら　　例）ボタンを押したら
Then ：～という結果になる　　　例）メッセージが出る

これらはOPAテスト実行時に設定されるオブジェクトで、それぞれarrangements, actions, assertions（というメソッドの集合）を持ちます。これらメソッドもテストケース作成時に実装します。

Arrangements：初期状態のステータスを定義する
Actions：ユーザの操作のよって起きるイベントを定義する
Assertions：実行結果が想定通りかのチェックを定義する

OPAテストはユーザの行動をイメージし、「話すように」テストケースを書くことから始まります。

OPAテスト用の設定を確認

今回のテストで使うファイルは、test/integrationフォルダの配下に格納されています。

OPAテストはopaTests.qunit.htmlから実行します。
各ファイル、およびオブジェクトの関係は以下のようになっています。
AllJourney.jsというファイルから、ページごとのテストが呼ばれるという構成です。

QUnitはjsファイル単位にテスト用jsを作成しましたが、OPAテストの場合はビューごとに作るのが基本です。各ビューに対応するテスト用js（例：Worklist.js）の中でPage Objectと呼ばれるオブジェクトを生成します。Page Objectの中にActions, Assertionsを記述します。Arrangementsは共通で使うことが多いので独立したファイルになっています。（Arrangementsのファイル名はStartjp.js）

Worklistを例に各ファイルのつながりを表すと以下のようになります。

OPA5でTest Driven Development

流れは前回のQUnitと大体同じです。

テストを書く
機能を実装する
テストを実行する

実装する機能

現状は全部のデータが一度に表示されます。
パフォーマンスを考慮し、一度にロードする件数を20件に制限します。さらに、"More"（日本語では"さらに表示"というボタンを押すと全データが表示されるようにします。

1. テストを書く

OPAテストでは、XXJourney.jsとXX.jsの2つのファイルが必要です。
XXJourney.jsが「話すように書く」テストで、XX.jsにJourneyで使うactionsとassertionsを記載します。

webapp/test/integration/WorklistJourney.js

変更前は以下のようになっています。

	opaTest("Should see the table with all posts", function (Given, When, Then) {
		// Arrangements
		Given.iStartMyApp();
		
		// Assertions：全レコードが表示された状態、かつタイトルに明細数が表示されている
		Then.onTheWorklistPage.theTableShouldHaveAllEntries().
			and.theTitleShouldDisplayTheTotalAmountOfItems();

		// Cleanup
		Then.iTeardownMyApp();
	});

初期状態が「全明細を表示」から「20件まで表示」に変わるので、それに伴ってテストの内容を変更します。

	opaTest("Should see the table with all posts", function (Given, When, Then) {
		// Arrangements
		Given.iStartMyApp();
		
		// Assertions
		//1. 改ページがされること
		Then.onTheWorklistPage.theTableShouldHavePagination().
		//2. タイトルに明細数が表示されること
		and.theTitleShouldDisplayTheTotalAmountOfItems();
	
	}); 
	opaTest("Should be able to load more items", function (Given, When, Then){
		// Actions: Moreを押したら
		When.onTheWorklistPage.iPressOnMoreData();

		// Assertions: 全件表示されること
		Then.onTheWorklistPage.theTableShouldHaveAllEntries();

		// Cleanup
		Then.iTeardownMyApp();
	});

テストケースを2つに分割し、最初のテストは新しい初期状態、すなわちページ番号が表示されることを確認しています。2番目のテストケースではMoreを押して全明細が表示されることを確認します。

webapp/test/integration/pages/Worklist.js

WorklistJourneyで使う新しいaction, assertionの処理を追加します。

Dependencyを追加

まず、dependencyにPressクラスを追加します。ボタンなどを押す操作で使うためです。

Actionを追加

actionsにリストの"More"ボタンを押す操作を記述します。

waitForによって指定したIDのビュー、テーブルが表示されるのを待ち、表示されたらボタンを押します。waitForを使わないと画面にUIエレメントが表示されるのを待たずにテストが進んでしまい、エラーになってしまいます。

waitForは以下の動きをします。

400 msごとに指定されたエレメントが表示されたかどうかチェックする
表示されればsuccessファンクション、または指定した操作が実行される
15秒待って表示されなければ失敗とみなし、errorMessageが表示される（15秒は初期値で、変更可能）

Pressについて、ここでは何を押すのか指定していませんが、UIコントロールによってデフォルトの動作が決まっているそうです。（変更したい場合は引数に対象のIDを渡す）
リファレンスを見ると、

Control Adapters will find the correct DOM Element

とあり、何らか押せるものがあればそれを押すのだと思われます。

Assertionを追加

リストが改ページされているか確認するassertionを追加します。

さきほどと似た構成ですが、ここでは実行結果が想定結果と合っているかのチェックを行います。想定結果はmatchersで定義します。Aggregation（リスト）の行数が20ある、という想定になっています。（テスト用のmock dataは23行なので、そのうち20行が表示されていれば正しい）
想定結果と実行結果が一致すればsuccessファンクションが実行されます。