Webサイトスクレイピングのサンプルで実践するRPAのテスト駆動開発：テストドリブン型のRPA開発のススメ（2）

RPAの品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する連載。今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて、UiPathを例に実践方法を説明する。

[井上秀和，UiPath]

　RPA（Robotic Process Automation）の品質向上、運用コスト削減につながるテストファーストなRPAにおける開発アプローチを紹介する本連載「テストドリブン型のRPA開発のススメ」。連載初回となった前回で、テストドリブン型の開発手法とRPAに適用した際のイメージ、そしてRPA開発のベストプラクティスが理解できたと思います。第2回となる今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて、UiPathを例に実践方法を説明します。他のRPAツールを使う場合でも参考になるかと思います。

RPAでのテストドリブン

　実装に入る前に、前回紹介したテストドリブン型のRPA開発の概念を再掲します。

1. テスト用ワークフロー開発：ワークフロー開発に着手する前に、開発予定のワークフローをテストするためのテスト用のワークフローを書く。この時点では、ワークフローが存在しないので、このテストは当然エラーとなる
2. 自動化ワークフロー開発：テストを成功させるための最低限のワークフロー
3. リファクタリング：ワークフローをリファクタリングしてきれいにする

テストドリブン型のRPA開発の概念（再掲）

　基本的に、IT開発のテストドリブン型開発と同じコンセプトで、実施するものとなります。「assertEqual」は利用できない場合もあるので、「IF（条件）」に置き換えていたりするものですが、基本的にはプログラムのものをワークフローに置き換えているものとなります。

サンプルのシナリオ

　ここからは、サンプルの自動化シナリオを使用して、テストドリブン型の開発手法を紹介します。下記は、サンプルの自動化シナリオとそのワークフロー単位での実装イメージです。

サンプルのシナリオ

テスト用ワークフローの開発

　では、テストドリブン型の開発を始めます。

　まず、シナリオ図の「1）UiPathのWebサイトよりイベント情報のリストをスクレイピング」に関して取り掛かります。「DownloadEvent」というワークフローとその正常処理をテストする「DownloadEvent_Normal_File_Test」というワークフローを用意します。

　「DownloadEvent」のワークフローの引数にはこちらの設定をしておきます。

方向	引数名	型	既定値	説明
入力	in_URL	String	"https://www.uipath.com/ja/news/events"	イベントページのURL
入力	in_MaximumNumberOfEvents	int32	10	イベント取得の最大件数
出力	out_ExtractDataTable	DataTable	-	イベント情報のDataTable

　「DownloadEvent_Normal_File_Test」に関しては、次の通りの構成とします。

1. 「DownloadEvent」への入力引数を設定
2. 「DownloadEvent」呼び出し
3. 出力引数の検証

　詳しく見ていきます。「url」には、イベントページをローカルに保存したHTMLを使用します。サーバで動いているページのURLにすると、イベント情報の更新に伴い、テスト実行タイミングで、出力引数の検証も変わってしまうので、ここではわざとローカルに保存したHTMLを使用し、スクレイピング後のデータ検証が正確なものとなるようにします。

　なおブラウザへは、絶対パスでURLを渡してあげる必要があり、次のように記載しています。

Path.Combine(Environment.CurrentDirectory, "Test_Data\イベント・セミナー RPAの最新情報 _ UiPath.html")

　「maximumNumberOfEvents」には、「10」を設定しておきます。

　次に「ワークフロー ファイルを呼び出し」において、「DownloadEvent」を呼び出し、「url」と「maximumNumberOfEvents」を入力引数へ渡します。

　その後、検証として、出力引数のeventDataTableのレコード件数が10件であるかどうかを検証します。10件ではないなら、「New BusinessRuleException("eventDataTable Count wasn't 10")」という例外をツール側にスローし、テスト失敗を通知します。

　別の検証として、1つ目のレコードの「title」が、「UiPath導入検討者向けハンズオンセミナー」であるかどうかを検証します。異なる場合は、その旨を知らせるための例外をスローし、テスト失敗を通知します。

New BusinessRuleException("Actual: " + eventDataTable.Rows(0).Item("title").ToString + Environment.NewLine + "Expected: " +  "UiPath導入検討者向けハンズオンセミナー ")

スローする内容

　最後に、1つ目のレコードの「url」が、「"https://www.uipath.com/ja/handson-seminar-20200327"」であるかどうかを検証します。異なる場合は、その旨を知らせるための例外をスローし、テスト失敗を通知します。

New BusinessRuleException("Actual: " + eventDataTable.Rows(0).Item("url").ToString + Environment.NewLine + "Expected: " +  "https://www.uipath.com/ja/handson-seminar-20200327")

スローする内容

　この時点では「DownloadEvent」の中身がない状態ですが、テスト用のワークフロー「DownloadEvent_Normal_File_Test」を実行します。UiPath Studioで「DownloadEvent_Normal_File_Test」のワークフローを開いて選択した状態で、「ファイルを実行」からこのワークフローを実行します。

　実行結果は当然ながら、1つ目の検証でエラーとなります。これでまずテストドリブンの1つ目の「テスト用ワークフロー開発」に関して完了です。

　なお、テスト用のワークフローは、テスト項目の単位で複数作成し、テストの網羅性を高めることを推奨します。「DownloadEvent」については、別のテストケースとして、サーバで動いているページのURLからデータを取得し、0件以上のデータが取得できることや異常系について別のテスト用ワークフローを用意し、品質強化を目指します。その他のテスト用ワークフローについては、後ほどの一覧で、簡単に紹介します。

ワークフロー開発

　テスト用のワークフローができたので、次のステップである「DownloadEvent」のワークフローの実装に移ります。既に「DownloadEvent」の引数については定義済みです。

方向	引数名	型	既定値	説明
入力	in_URL	String	"https://www.uipath.com/ja/news/events"	イベントページのURL
入力	in_MaximumNumberOfEvents	int32	10	イベント取得の最大件数

　テストドリブン型開発では、最初にテスト用のコードを準備しますが、UiPathの場合、引数の「既定値（デフォルト値）」というものが、便利に使用できます。これは、ワークフローにインプットで渡す引数に関して、呼び出し元からの指定がない場合、既定値として使用される値を、そのワークフロー自身に定義できるというものです。

　こちらを使用することで、最低限のテストケースとして、「最後までワークフローが稼働するかどうか」を単体テストとして、そのワークフローのみで検証することができます。

　「DownloadEvent」のワークフローに関しては、「ブラウザーを開く」と「データスクレイピング」を組み合わせるものとなります。ひとまず、このワークフロー単体で動かし、エラーとならなければ最低限のテストケースは「クリア」となります。

　ワークフロー単体が問題なく動くことを確認した上で、早速テスト用のワークフローからのテストも試します。先ほどと同様に、UiPath Studioで「DownloadEvent_Normal_File_Test」のワークフローを開いて選択した状態で、「ファイルを実行」からこのワークフローを実行します。

　今回は、どのような結果になるのでしょうか。エラー（例外）が発生しなければ、テストはクリアですが、通常ここで何度もエラーが発生します。そのエラーを修正、再テストを繰り返し、ワークフローを完成させます。テスト用のワークフローが、最後までエラーなしで終了すれば、テストドリブン型開発の2つ目の「自動化ワークフロー開発」は完了です。

リファクタリング

　テストドリブン型開発の最後のステップとして、リファクタリングがあります。これは、前段のステップで取りあえず最後まで動くようになったワークフローを、より良いものに改修していく工程です。RPAに関しては、「待ち処理の見直し」「自動化対象システムの要素特定方法の安定性向上」など幾つか、リファクタリングのポイントがあります。

　リファクタリングに関しては、テスト用のワークフローのおかげで、ワークフローの修正後にこれを実行するだけでその実装結果の良しあしが簡単に判別できます。リファクタリングが完了すると、テストドリブン型開発の3つ目の「リファクタリング」が完了となり、一連の流れが終了したものとなります。

その他のテストケース、ワークフロー

　「DownloadEvent」に関しては、その他のテストケースとして、ファイルではなくURLから正しくスクレイピングが行え、結果がDataTableとして取得できることがあります。エラーのケースとして、URLが不正な場合、イベントページの仕様が変わりスクレイピングが失敗するケースをテスト用のワークフローとして作成します。

　「FilterEvent」「SendMail」についても、同様にテストケースを作成し、それに合わせたテスト用ワークフローを作成していきます。

ワークフロー	テスト用ワークフロー	テスト項目	テスト用のワークフローの結果（期待値）
DownloadEvent	DownloadEvent_Normal_File_Test.xaml	ローカルのHTMLからスクレイピングが行え、DataTableに変換できること Assert項目 ・スクレイピング後のDataTableのレコード件数が10件であるかどうか ・1つ目のレコードの「title」が、"UiPath導入検討者向けハンズオンセミナー"であるかどうか ・1つ目のレコードの「url」が、"https://www.uipath.com/ja/handson-seminar-20200327"であるかどうか	Success
	DownloadEvent_Normal_Web_Test.xaml	URLからスクレイピングが行え、DataTableに変換できること Assert項目 ・スクレイピング後のDataTableのレコード件数が0件ではないこと	Success
	DownloadEvent_Error_Test.xaml	URLに誤りがある場合やイベントページの仕様が変わりスクレイピングが失敗するケース	SystemException
FilterEvent	FilterEvent_Normal_Test.xaml	Assert項目 ・フィルタリング後のDataTableのレコード件数が8件であるどうか	Success
SendMail	SendMail_Normal_Test.xaml	Assert項目 ・下書きフォルダにドラフトメールが生成されているかどうか	Success

　基本的に正常ケースであれば、「IF(条件)」をAssertとして使用することで期待通りのアウトプットか否かを検証し、正常であればテスト用のワークフローは何事もなく終了します。例外発生においては、Assertでの失敗もしくはその他の問題が考えられます。

　一方で、異常ケースの場合、わざとインプットに問題のものを入れ、それが正しく異常として処理されるかどうかを確認したいものです。この場合、テスト用のワークフローの結果が、例外として終了するかどうかで判断するのが一つの手となります。上記テーブルの「テスト用のワークフローの結果（期待値）」は、これを意味します。

　なお、異常ケースにおいて厳密に例外の種類も検証する場合、「Try Catch」を用いて、検証します。

次回は、テストの自動化と継続的インテグレーション

　今回は、テストドリブン型のRPA開発方法について、具体的なケースを用いて説明しましたが、いかがでしたでしょうか。実践するためのイメージがつかめたかと思います。次回は、今回テストドリブン型の開発で作成したテスト用ワークフロー全てを一括で実行し、結果を確認する方法を紹介し、その自動化したテストが継続的に実行できる環境を作ります。

筆者紹介

井上秀和

データスクレイピング、データマイニング、UIオートメーションをRuby、Python、そしてUiPathで行うことを得意とする。オブジェクト指向を好み、デスクトップOSは、昔Solaris、ちょっと前Ubuntu、最近macOSを愛用。

IT業界で、プログラマー、プロジェクトマネジャー、ビジネスアナリスト、コンサルタントといった役割で、モバイルアプリやWindowsアプリ、Webアプリ、トレーディングシステムの開発、構築、および業務改善に従事。現在は、RPA業界で業務自動化をライフワークとしている。