読者です 読者をやめる 読者になる 読者になる

SQiP2016 併設チュートリアルに参加しました (キーワード駆動テスト)

SQiP併設チュートリアルのキーワード駆動テスト勉強会に参加してきました。

www.juse.jp

 

目的

  • キーワードの粒度、他の方がどのように設計しているのか知りたい。
  • 他の方のシナリオテストの準備、検証をどういう考えで実装しているか知りたい。

 

内容

今回は.NET Frameworkを使った計算機アプリのシナリオテストを、Friendlyというフレームワークをベースとして書かれたMS PowerShellで実装していくという内容でした。

 

講義

キーワード駆動の概念といった基礎的なお話から、キーワード駆動とテストスクリプトの違い、メリット・デメリットについて教わりました。

デメリットについては、特に「テストケースの増加に伴い、キーワードスクリプト間で重複する部分が出現し、テストのメンテナンスコストを下げる可能性がある」という点が紹介されました。

 

チュートリアル

キーワードスクリプトを変更するところから始まり、キーワードテストランナーの改修といった点を学びました。

 

f:id:jugemix:20160920204804p:plain

このクラス図は、チュートリアルの資料の取扱いについて小井土さんから許可を頂いたので、テスト実行の入力となるデータも追加して全体の構造を表現してみました。

 

f:id:jugemix:20160920211952p:plain

これが具体的なテスト流れRunTest.ps1の概要です。

(ループ部分は割愛してます)

 

アクティビティ図を見ると、今回の実装方針ではテストケース(キーワードスクリプト)の実行をつかさどるテストランナーと、テストケースの読み込み、テストセットの実行(テストケースの繰り返し実行)、テスト結果の比較が独立していることが分かります。

これは、今回のテストシステムの設計がキーワード駆動テストのデメリットである「共通部分の重複」を排除することを意識している為です。

 

f:id:jugemix:20160920214624p:plain

これはテストケース実行処理部分=テストランナーのフローです。

 

例えば、ログイン→商品選択→決済→ログアウトというシナリオがあったとき、①商品選択だけ1つも選ばない、②1つ選ぶ、③配送しきれないほど選ぶ―といったバリエーションを持たせてテストをたいとします。

 

これをキーワードスクリプトに書くと、スクリプト上に①~③で3回ログイン、決済、ログアウトが現れます。

 

今後のメンテナンスでログイン処理に手が加わったらどうなるでしょうか。

上記のテスト3スクリプトとも直さなければ動かないテストになってしまいます。

 

アプリケーションの修正に伴い、自動テストもメンテナンスは必要です。

この前提に立って、3つを直すより1つを直す方が運用しやすいという考えの元、ランナー側で共通部分を実行するように実装していました。

 

実運用ではアプリケーションのライフサイクルを考慮して、ランナーを設計することが望ましいと思います。(私見)

 

自動テストシステムにおけるランナーの役割は、テストの実行順や実行方法の制御だけでなく、キーワードスクリプトにおけるコードとして実装された共通処理を実行するという役割も担っていました。

 

後日 JUnitで実装する場合の調査

同じことを自分の作る自動テストシステムでも実現できるかな?と、JUnitのランナーの構造について後日調べてみました。

 

JUnitの場合は、@Beforeや@Testといったアノテーション付のメソッドブロックをその名もBlockJUnit4ClassRunnerが、methodBlockメソッドでStatementというテストの文脈(実行順のようなもの?と理解してます)オブジェクトを作り、ParentRunnerのrunLeafメソッドでオブジェクトの一つ一つを実行することでテストを実行しています。

 

もしテスト実行の共通処理をまとめるのなら、BlockJUnit4ClassRunnerのサブクラスでmethodBlockメソッドをオーバーライドするか、methodBlockが呼び出すInvokeMethodクラスのmethodInvokerサブステートメントを実装する感じになりそうでした(JavaDocにもそう書いてありました)

この為、JUnitを使う場合でもカスタムランナーで吸収することは出来そうです。

これもParentRunnerがrunChildメソッドを子クラスに委譲してくれているおかげかなと思います。

 

ただ、JUnitの構造を理解するところから理解する必要があり、長くなりそうなのでまた後日記事にまとめます。

 

参加してよかったこと

  • ランナーを使ったテストケース間で重複したテストコードの排除の方法
  • 想定結果の準備方法
  • テスト結果の検証方法はテストの目的によって異なるので、自動化する前にテストを設計すること
  • 回帰テストは前回のテスト結果と比較すると良いこと
  • バグの再現手順をテストケースとして実装すると良いこと

 

自分がキーワード駆動テストシステムを作る上で参考になる知見、気づきを得ることが出来ました。もっと実践と研究を繰り返すことで、世の中の自動化に寄与するアイディアを生み出せるんじゃないかなーと思うようになりました。

 

参加してよかった。