agileツール適合化分科会（tddとbdd）

1Copyright (C) Masanori Kataoka, All Rights Reserved.

Testing Framework(TDDとBDD)～JUnit, JBehave, SeleniumWebDriver～

２０１５年１２月８日

片岡雅憲

2015/12/111

Agileツール適合化分科会（第８回）資料


＜内容＞

１．テスト自動化の必要性２．テスト自動化の推進戦略３．テスティングフレームワーク４．TDDとJUnit

５．機能テストとその支援ツール６．GUIテストとその支援ツール７．Selenium

８．Selenium WebDriver

９．BDDとJBehave

＜参考文献＞


１．テスト自動化の必要性

テスト自動化を必要とする背景として次があげられる。１）ITの利用範囲の拡大、技術の進歩と共にテスト工数負荷が急拡大しつつある。ソフトウェア開発規模そのものが拡大している。また、ソフトウェアの既存部品、コンポーネント、サービスを活用することが進んでいるが、これら既存ソフトウェア部分についてもテストが必要とされる。急速なテスト作業量の増大に対応するために、テストの自動化が強く要請されている。２）ビジネスや技術革新の加速化に伴いテスト期間の短期化が強く要求されており、テスト自動化が必須になっている。３）テスト作業は、多くの単調な仕事と、少量だが高度の緻密性を要求される仕事の組み合わせで構成されている。このため、作業者のモティベーションが下がりがちである。単純作業の部分を自動化して、作業全体の質の向上を図る必要がある。４）ITシステムの社会的重要性が増してきて、コンプライアンス上からテスト証跡が求められることが出てきている。


２．テスト自動化の推進戦略

2.1 テスト自動化の推進戦略テスト自動化の必要性は理解しても、実際にそれを推進するとなると多様な困難に直面することになる。ただやみくもに自動化を進めるのではなくテスト作業全体を考慮に入れた自動化戦略が大切である。テスト自動化戦略は、次の基本要素にしたがって立案されるべきである。① テスト対象となるソフトウェア構造② テスト作業のライフサイクル（テスト仕様の作成、テストデータの作成、テスト実行順序の決定、テスト環境の作成、テストの実行、テスト結果の検証、不良の分析・管理、テスト進捗状況の管理）

③ 標準化（被テストソフトウェアの標準化、テスト資産の標準化）④ 既存テスト資産の蓄積・再利用



2.2 テスト構造ピラミッドテスト作業では、小さな単位のテストから始めて、これを順次に大きな単位へと組み上げてテストしていく。テスト自動化技術もこれに対応していく必要があり、図2.1 に示すようなテスト構造ピラミッドが形成される。

１）単体・コンポーネントテストでは、システムの内部構造に基づく最小単位でのテストを行う。また、これと共に、コードの分析・検証を行う（これを静的テストと呼ぶことがある）。これらにより、最小単位での正しさを検証して、不良を早期に検出出来る。このテストは、「内部仕様に基づくテスト」ということが出来る。２）機能テストでは、システムを外部から使う観点でのテストが行われる。また、GUIテストではGUIの妥当性を含めた機能テストを行う。したがって、これらのテストは、システムの「外部仕様に基づくテスト」と位置付けることが出来る。



図2.1 テスト構造ピラミッド

単体・コンポーネントテストおよびコード分析・検証

機能テスト(API Layer)

GUI

テスト

システムテスト

リリーステスト

2.2 テスト構造ピラミッド（続き）３）システムテストでは、システム全体の特性としての、ユーザビリティ、セキュリティ、性能等についてのテストを行う。４）リリーステストでは、顧客が実際に使用する実システム環境下、または、それと全く同等の環境下でテストが行われる。すなわち、システム環境自体とソフトウェアとの整合性もテストの対象となる。５）上記のうち、１）２）は、１００％の自動化をしていく。３）４）については、一部に手作業が入るが、極力自動化することが望ましい。



2.3 テスト作業のライフサイクル一言でテストと言ってもその内容は次のような複雑なライフサイクルで構成されている。テスト自動化を推進するに当たってはテスト作業のライフサイクルのどの部分を自動化するのかを明確にしなければならない。１）テスト仕様（テストケース）の作成設計仕様に基づきテスト仕様を作成し、文書化する。TDDではテスト仕様＝設計仕様との考え方になっている。２）テストデータの作成十分なテストカバレッジを実現するテストデータを作成する。

３）テスト実行順序の決定テストの相互依存関係を考慮に入れてテスト実行順序を決定する。

４）テスト環境の作成テスト実行に必要とされる環境を作成する。初期設定、未作成モジュールのスタッブの作成、関連サービスの仮想化などを準備する。



2.3 テスト作業のライフサイクル（続き）

５）テストの実行テストを実行する。３）テスト実行順序の決定に基づいて、繰り返し実行、連続実行、条件付き実行などが指定できる必要がある。６）テスト結果の検証期待するテスト結果が得られているかどうかを自動検証する。

７）不良の分析・管理期待するテスト結果が得られなかった場合に不良の原因を分析し、不良を修正する。また、その経緯を管理する。８）テスト進捗状況の管理テストの実行状況、合格状況、不良の検出・修正状況等、テストのの進捗状況を管理する。



2.4 標準化と自動化どのような作業であっても、自動化の前提として標準化が必須である。すなわち、テスト対象とするソフトウェアをあるがままにテストし、それを自動化する、との考え方ではなく、テスト自動化に適したソフトウェア構造とすることが大切である。すなわち、テスト自動化を意識したソフトウェアの設計を作り込むことである。具体的には、次のような点に配慮することが望ましい。１）命名規則（機能、モジュール、テストケースの間の対応付けが自動化できるような命名規則）２）単位機能の独立性の確保３）モジュール化の徹底４）機能間、モジュール間の相互関係の把握（改造時の影響範囲、再テスト範囲の把握の自動化を可能とする）

また、上記と対応したテスト資産についても標準化を徹底していく必要がある。



2.5 テスト資産の再利用とテスト自動化テスト資産を標準化して、蓄積・再利用することにより、自動化の効果を上げ易くなる。例えば、次の観点からのテスト資産の再利用に基づく自動化が大切である。１）既存テストとテスト結果の再利用によるリグレッションテスト２）入力データの一部を変更しながら、何度も繰り返し実行する必要があるテスト３）入力項目、入力データ量が多いデータ入力系のテスト（入力項目、データのテーブル化とテストプロセスのProfiles化）４）複数環境（OS、ブラウザ、スマートフォン）でのテスト５）仕様変更が少ない機能のテストでの既存テスト資産の再利用６）他のサービス(SaaS)との連携機能のテスト７）大きなテストケースをそのまま自動化することは望ましくない。小さなテストケースに分解してモジュール化し、それを結合する形で大きなテストケースを組み立てるべきである。


３．テスティングフレームワーク

3.1 テスティングフレームワークとはソフトウェアのテスト作業は極めて複雑な作業であり、その自動化を推進するに当たっては、前章２．テスト自動化の推進戦略に述べたような枠組みを予め考慮に入れておく必要がある。このようなテスト用の標準的な枠組みをテスティングフレームワーク(Testing Framework)と呼ぶ。テスティングフレームワークは、テストに必要とされる各種の機能や環境を標準的に提供し、結果としてテスト作業効率を大幅に改善する。代表的なテスティングフレームワークとしてTDD(Test Driven

Development)とBDD(Behavior Driven Development)がある。その名が表すようにTDDもBDDも自らをテスティングフレームワークとは呼ばず開発用のフレームワークであると称している。しかし、「開発」に於いてはTDD, BDDがカバーする以外の多くのものが必要とされる。ここでは、TDD, BDDがテスト作業に於いて著しい効果を上げることから、テスティングフレームワークとして位置付けて議論を進める。


３．テスティングフレームワーク

3.2 TDDとBDD

TDDは、Kent Beck等によって開発された単体テスト用のフレームワークである。したがってまた、内部仕様テスト用のフレームワークであるとも言える。TDDは、これを支援するためのツールであるJUnit等と共に普及し、今や極めて標準的な技術となっている。一方、BDDは、機能テスト、システムテスト用のフレームワークであり、外部仕様テスト用のフレームワークである。BDDも提案されて以降、かなりの歴史を重ねてきているが、必ずしも十分な普及を見て来なかった。しかし、今や、機能テスト、システムテストの自動化へのニーズが極めて高くなってきていることからBDDへの関心が強まってきている。例えば、Webシステム向けのGUIのテストやクラウドシステム間の連携における運用テストでは、自動化へのニーズが極めて高い。また、このようなニーズを背景としてツール面での改良も積み重ねられてきた。本稿では、以下、TDDとBDDを対比しながらテスティングフレームワークの機能とその効果を見ていくこととしたい。


４．TDDとJUnit

ＴＤＤは、単体・コンポーネント（以下「単体」と省略）テスト用のテス

ティングフレームワークである。単体テストは、ソフトウェアの内部構造上の最小単位である単体に対するテストである。したがって、内部構造、内部仕様面からのテストと言える。TDDはこれを支援する。

単体テストは、プログラムコードを新規に開発した場合、あるいは改造を加えた場合に、その正しさを検証するための基本的なテストである。新規開発あるいは改造したコードと、それに対応するモジュール単体、あるいはコンポーネントとは直接的な関連付けが出来る。したがって、このテストにより、不良が早期に検出できることが特徴である。

単体・コンポーネントは、それ単独では動作しない。したがって、当テストを実行するためには、JUnit等のテスティングフレームワークや関連モジュールをシミュレートするMock等の仕組みが必要になる。


４．TDDとJUnit

4.1 TDDと単体テスト１） TDDとは

TDD(Test Driven Development：テスト駆動開発）は、テストを主体としたソフトウェア開発法である。テストを先に記述し、それに合格する様にコードを開発する。

TDDのキイワード：Red/Green/Refactor―最初はテストだけなので不合格（赤）、コードを書いてテストに合格（緑）、そしてそれを磨いてきれいにする（リファクタリング）。

―Test a little/Code a little/ Refactor a little(少しづつ着実に進む)

＝＞テストを繰り返し実施する必要があり、テストの自動化が、必須である

テスト

コンパイル

動作

リファクタリング

図4.1 TDDの手順(Red/Green/Refactor)


４．TDDとJUnit

4.1 TDDと単体テスト（続き）２） TDDは、単体テスト支援フレームワーク xUnit と共に発展してきて、今や主要な単体テスト技術となっている。xUnitはTDD作業の自動化のためのツールであり、フレームワークであると言うことが出来る。xUnitは、XPの開発者として有名なKent Beckが開発したものであり、現在はそのうちでもJUnit4.0が最も多く使われている。

３） xUnit の”x”の部分にはテスト対象プログラムの記述言語により多様な文字が埋め込まれるが、JUnitがその代表とみなされている。

４） xUnitは、次の部分から構成され、総合的にテスト作業を支援する。―テストコンテキスト：テストを実行、成功させるための前提条件の集合、テストフィクスチャとも呼ばれる。

―テストスィート：同じテストコンテキストを共有するテストの集合―テストの実行環境：テストのための環境を準備し、テストを実行し、実行後の環境を実行前のクリーンな環境に戻す。

―アサーション（表明、検証）環境：テストの成否を確認する。


４．TDDとJUnit

4.2 JUnitを使ったテストの秘訣１）少しコーディングしたら、少しテスト２）出来るだけ頻繁にテスト（少なくともコンパイル回数以上）３）１日（１晩）に一回は、全てのテストを実行４）もっとも危険だと思っている個所から先にテスト５）テストへの投資の収益が最大になるようにテストを書く６）機能を追加するときは、最初にテストを書く７）デバッグをしていて、system.out.println() を使っているようなら、代わりにテストケースを書く

８）バグが報告されたら、それが見つかるようなテストを書く９）誰かにデバッグの協力を頼まれたら、テストを書いて協力する１０）全てのテストにパスしていないソフトウェアを配布しない


４．TDDとJUnit

4.3 JUnit による効果JUnit は、単体テスト用のフレームワークとして位置付けられ、次のような効果をもたらす。１）単体テスト作業を標準化する。２）その結果として、作業環境、作業手順、関連ツールを作業者間で共有可能とする。また、保守性を向上させる。

３）ソースコードとテストコードを分離する。４）回帰（regression、デグレード防止）テストを自動化する。５）他のツールとの連携を容易にする。例えば、Eclipse配下のツールとして次のような連携を可能とする。－テスト支援ツール配下の一機能として起動される－Ant, Maven 等のビルドツールから自動起動される（デグレード防止テストの自動起動）


4.4 JUnitのアノテーション(annotation)機能現在、最も用いられてJUnitのバージョンは、JUnit4.Xである。

JUnit4.0で新たにサポートされたアノテーション機能はテストを効率よく実行する上での効果が大きい。アノテーションとは、テストメソッドにメタデータを注釈の形で付与することであり、例えば次がある。@Test – そのメソッドがテストメソッドであることを示す。従来のJUnitでメソッド名がtestで始まるメソッドと同じ。

@Before – このメソッドは、@Testアノテーションが付いたメソッドを実行するたびに事前に実行される。以前のsetup()メソッドと同じ。

@After – このメソッドは、@Testアノテーションが付いたメソッドを実行するたびに、後から実行される。以前のtearDown()メソッドと同じ。

@BeforeClass – このアノテーションが付加されたメソッドは、そのテストクラスを呼び出す前に実行される。

@AfterClass – このアノテーションが付加されたメソッドは、そのテストクラスを呼び出した後に実行される。

４．TDDとJUnit


４．TDDとJUnit

4.5 JUnitの高度の機能JUnitは、以上述べてきた基本的な機能以外に次のような高度の機能を提供している。

4.5.1 Assertion機能１）テスト結果の検証機能は、AssertクラスのassertThatメソッドにより提供されている。このメソッドにより、テスト結果が期待通りになっているかどうかを検証する。

２）検証に当たってのテスト結果の比較対象は、Matcherオブジェクトで指定する。MatcherオブジェクトのAPIは、HamcrestというJUnit

の拡張ライブラリで提供されている（Hamcrestは、JUnit4.4で本体に組み込まれたが、JUnit4.11で本体から切り離された）。Hamcrestは、極めて豊かな比較機能を備えており、今ではJUnit

の利用に於いて欠かせないものになっている。


４．TDDとJUnit

4.5 JUnitの高度の機能（続き）4.5.2 様々なテストランナーテストの実行機能を提供する手段として、JUnitは次のような様々なテストランナーを備えている。１）JUnit4：テストクラスのすべてのテストケースを実行する２） Suite: 複数のテストクラスをまとめて実行する。次のようなアノテーションで指定する。

@RunWith(Suite.class)

@SuiteClasses({ATest.class, Btest.class})

3） Enclosed: テストケースが多くなった場合に、階層構造化して初期化処理等を共通化する。Enclosedはこのように構造化されたテストを実行する。

４） Theories: パラメータ化したテストケースを実行する５） Categories: 特定カテゴリのテストケースをまとめて実行する。カテゴリは、@Categoryアノテーションで指定する。


４．TDDとJUnit

4.5 JUnitの高度の機能（続き）4.5.3 Ruleの活用

Ruleは、JUnit4.7から提供されているテスト実行方法の拡張木のである。標準Ruleとして表4.1のRuleが提供されている。

項番Ｒｕｌｅ名称機能

１ TemporaryFolder テンポラリフォルダの作成と開放

２ ExternalResource 外部リソースを扱うカスタムルール定義の基底クラス

３ Verifier テスト後の事後条件を検証する

４ ErrorCollector テスト時の例外の扱いをカストマイズする

５ ExpectedException 例外に関する詳細な検証を行う

６ TimeOut テスト時のタイムアウトを制御する

７ TestWatcher テストの実行時の記録を行う

８ TestName 実行中のテストメソッドのメソッド名を参照する

表4.1 JUnitが提供するRule


４．TDDとJUnit

4.6 JUnit と共に用いられる他の単体テスト支援ツールJUnitは、単独ではなく次のようなツールと連携しながら実行される。

１）モックオブジェクトの作成：EasyMock, jMock, djMock(Virtual Mock Object)

（注）djMockは、テストカバレジを測定する機能も持っている２）データベースアクセスを伴う単体テスト支援：

DbUnit, S2Unit

３）サーブレット、EJB, JSP 等の単体テスト支援：Cactus, StrutsTestCase

４） HTTP通信をエミュレート：HttpUnit

５）テスト実行時の作業を支援：Automated Continuous Testing（詳細は4.6で後述）

６） JUnitを総合的に支援：Eclipse TPTPのTesting Tools（詳細は4.7で後述）


４．TDDとJUnit

4.7 Automated Continuous TestingによるJUnitの作業効率向上EclipsのAutomated Continuous Testingは、JUnitによるテスト実行時の作業を支援するための次のような機能を提供している。１）Automated Continuous Testingではテストコードを保存した時点（Just In Time）でテストを実行し、結果を表示することが可能である。テストコードを作成しながらタイムリーにテストを実行し、テスト失敗の原因をすぐに修正したい場合に有効な機能である。２）JUnitでは、常に同じ順序でテストが実行される。Automated

Continuous Testingを使用することで、テストの実行順序をカスタマイズしたり、必要なテストのみを選択し、実行させることが出来る。テストの実行順序の調整やテストのフィルタリングは、Automated

Continuous Testingが提供するフィルターを用いて行われる。３）Automated Continuous TestingではJUnitの実行結果リストから必要な情報のみを選択して表示させることが可能である。


４．TDDとJUnit

4.8 Eclipse TPTPのTesting Tools

Eclipse TPTP(Test and Performance Tools Platform)

の機能の一つであるTesting Toolsでは、JUnitによるテスト作業に関連する次に様な支援機能を提供している。１）テストエディタと呼ばれるGUIエディタを通してテストクラスおよびテストスイートの編集・管理を可能としている。テストを実行するために必要となるリソースや実行環境、配備などについて定義したテスト資材を、テストエディタを使用することで簡単に作成することが出来る。２）TPTPはテスト結果をテストログファイルとして作成する。このテストログファイルを基に、テスト結果の統計を作成し、HTMLレポートとして出力する。３）ローカルホスト上でのテストだけでなく、エージェントコントローラが起動しているリモートホストでのテスト実行を簡単に行うことが出来る。４）テストデータを管理するDataPoolという機能を提供する。DataPool

機能では、専用のGUIエディタによりテストデータを編集出来る。


４．TDDとJUnit

4.9 TDDの課題「TDDの皮肉は、それがテスト技法で無いことである」と言われる。

TDDは、TDDは、開発技法であり、テスト技法ではないと主張されている。これに対して次のような批判がある。１）本来「テスト」とは、開発作業全体の一部の作業を示すものであり、それが開発の主体となることに抵抗がある。TDDでは、①テスト ②コーディング ③リファクタリングの順序で行われ、設計が③リファクタリングで代替されて、一番後になっている。

２） TDDの考え方は、単体テスト作業の改善と共に生まれてきており、テストがコードの内部構造に強く依存することになる。このために、内部構造を大きく変更すれば、テスト自身も大きく作り直さなくてはならない。

３） TDDのテストは、テストといいながら設計を含んでいる。これらの批判に対してBDD（詳細は後述）等での対応が図られている。


５．機能テストとその支援ツール

テストピラミッドの第２層として機能テストがある。機能テストは、ストーリーテスト、APIテストとも呼ばれることがある。機能は、単体・コンポーネントを組み合わせて実現され、ユーザから見た API(Application Program Interface) を提供する。また、GUIを実現するための”Behind GUI” を提供する。

単体テストが、モジュール内部の作り方も意識した”White Box Test”

（内部仕様テスト）であるのに対して、機能テストは、モジュール、モジュール群の外部から見た機能をテストする “Black Box Test” （外部仕様テスト）となっている。単体テストでは、内部構造を意識しているので、多様な入出力の組み合わせをテストするには工数的な限界がある。一方、機能テストでは、入出力の組み合わせの作成を容易にしていることから、これが可能になっている。また、機能テストは、顧客にも内容が理解できる点が強みである。



5.1 APIテスト支援ツールAPIのテストのためには多様な入出力の組み合わせのテストが必要であり、たとえば、次のようなツールがある。１） Fit(Framework for Integrated Test)

テストケースを表形式（MS Excel/Word等の形式）で記述し、ユーザと開発者との間のコミュニケーションを良くする。Java, C#, C++,

Python に対応している。Fitは、OSSである。現状では日本語版はない。Fitは、Wikiの発明者である W. Cunninghamが開発した。図5.1にFitによるテストの例を示す。

２） WebDriver(Selenium2)

WebDriverは、GUIテスト用の機能をAPIで提供する。近年Webシステムの比率が大きくなるとともに、GUIテストのニーズが拡大し、その道具としてWebDriverが広く活用されるようになってきている。

WebDriverについては、より詳細を後述する。


＜テスト内容＞このビール会社は様々なタイプの飲料を販売している。大きく分けると、季節商品（seasonal）と通年商品（year-round）、という2つのカテゴリーに分類することができる。すべての飲料はケース単位で販売され、複数ケース買いに対する値引きサービスがある。

図5.1 Fit を用いたテスト




5.1 APIテスト支援ツール(続き）３） DSL(Domain Specific Language:応用領域固有言語）

DSLは、各々のアプリケーションドメインに適した記述方式（API、図表形式等）で入力と出力の関係を記述して、これにより多様な組み合わせ条件のテストを実施する。例えば、ThoughtWorks社のテスト支援ツール twist は動的スクリプト言語Groovyにより、DSL相当の記述を可能としている。（注：Groovyは、Java環境下で動作するスクリプト言語であり、Java

にRubyの長所を取り入れている）

後述するBDD支援ツールJBehave, CucumberもこのようなDSLの一つである。また、Rubyは様々なDSLを作成（記述）するためのメタ言語として活用されていて、それは更に広がっていく動向にある。



5.2 TestNG(Testing, the Next Generation)

JUnitは、単体テスティングフレームワークの代表的な存在であるが、このTDDの考え方と機能を引き継ぎながら、かつ、その限界を打ち破るものとして、TestNG(Testing, the Next Generation)がある。TestNGは、Java SE5.0から導入されたアノテーション機能を用いる等により、結合テスト、機能テストに向けた次の特徴を実現している。１） Java SE5.0のアノテーション機能をサポート２）テストにおける各種の設定をXMLで記述可能３）前後処理のタイミングを細かく指定出来る４）テストをグループ化することが出来る５）テスト間に依存関係を作れる６）テストを並列実行出来る、スレーブマシンで分散実行出来る７） Antからテストを実行出来る８）これら１）～７）の特徴により、単体テストだけに限らず、機能テス

ト、結合テスト、統合テスト他にも利用できる



5.3 TestNG対xUnit

TestNGは、xUnitに物足りなさを感じたGoogle社のエンジニアが開発したものである。TestNGは、アノテーション機能を活用して、テストの自動化をより深めたこと、テスト間の依存関係やグループ関係を指定可能にして結合テストを可能にしたことなどで、JUnitよりも高度の自動化を推進した。一方、JUnitの方でもこのような動きを見て、JUnit4.0でアノテーション機能を取り入れるなどの改善を図ってきている。しかし、単体テスト支援機能の改善に的を絞っている。このようなことから、しばしば、TestNG対JUnitの関係についての議論が行われる。この議論に、まだ決着はついていない。現在の状況では、単体テストでは、JUnitを、結合テストではTestNGを、うまく組み合わせて使うのが現実的と捉えられている。



5.4 Eclipse TPTP(Test and Performance Tools Platform)

Eclipse TPTP は、Eclipse環境においてテストを単体テスト、機能テスト、性能テストについて、総合的に支援するテスト支援環境である。TPTP配下で他のテスト支援ツールを動かすことも出来る。

TPTPは、次の機能から構成されている。１） TPTP Platform: 共通インフラ機能２） Testing Tools: JUnitをテストの編集、実行面等から支援３） Monitoring Tools: モニタリングやログ解析等の性能評価、

分析機能４） Tracing and Profiling Tools: 実行状況のトレースやリソース

（CPU、メモリ等）の使用状況の分析


６．GUIテストとその支援ツール

6.1 GUIテストの自動化の重要性近年、GUIテストの自動化は、極めて重要なものになって来ている。１） GUIベースのAP の急増

GUIベースのAP(Application Program)は、これまでも急増してきたが、今後とも更なる増加が見込まれる。a) 情報の共有、統合化を目的としたネットベースのAPの増加、そして、そのGUIとしてのWebの活用。

b) スマートフォンの出現が、上記を加速化。c) GUIの利用は、Androidなどを活用した組み込み機器にも拡大。２） GUIテストの自動化が必須

a) GUIのテストの全てを手作業で行うには膨大な工数がかかると共に、確認漏れ等の信頼性の問題が生じる。

b) ビジネスが加速化される中で、WebApに対する短期間、高頻度の改変要求が生じる。改変に伴うデグレードを防止するためのテストの自動化が必須となって来ている。


６． GUIテストとその支援ツール

6.2 主なGUIテスト支援ツール１） Selenium: Seleniumは、OSSベースのWebApテスト自動化支援システムの代表的な存在である。Webブラウザを実行させるためのスクリプトを記述し、それを実行させることが出来る。このことにより、手間をかけて手動で実行していたWebApのテストを自動化することが出来る。Seleniumについては、その詳細を７．８．で説明する。

２) Watij(Web Application Testing in Java): Web, Javaアプリケーション向けの総合テスト支援ツール。Ruby向けのテスト支援ツールWatirのシンプルさを引き継ぎながら、Java向けの機能を強化している。（Seleniumよりも使い易いという人もいる。しかしながら、現状においては、Seleniumと比べて日本での普及は遅れている。）



6.2 主なGUIテスト支援ツール（続き）３） Jameleon：Javaアプリケーション向けの総合テスト支援ツールである。Jameleon のテスト記述スクリプトは,Jelly スクリプト(XML

ベースのスクリプト）となっている。Jameleon は、OSSである。Jameleonは様々なテストを支援していて、次のプラグインがある。―JUnit：ユニットテスト用のフレームワークを提供―HttpUnit：HTTPレベルでのテスト用フレームワークを提供―jWebUnit：WebApのテスト用フレームワークを提供―Jiffie：IEを利用したテスト用フレームワークを提供―Jagacy：MF用の3270端末エミュレータ対応プラグインJameleonのテストケースは複数のセッションに、セッションは複数のファンクションポイントに分解され、これには次の３種類がある。

―アクションポイント：フォーム、ボタンが正しく動作することを検証―バリデーションポイント：出力が正しいことを検証―ナビゲーションポイント：リンクによる遷移が正しいことを検証


６． GUIテストとその支援ツール

6.2 主なGUIテスト支援ツール（続き）４） QTP(Quick Test Professional): Mercury社の製品。現在は、同社をHP社が買収したためHP社の製品となっている。Webアプリケーションの機能テストを支援する。テストオペレーションを自動記録して、そのオペレーションの中で確認すべきポイントと内容を指定していく。それが、VBScriptに展開され、再テストで利用できる。そして、このテストスクリプトは、編集することにより他のテストスクリプトへと再利用できる。

QTPは、総合テスト支援ツールとして、他のツールと比べて完成度が高く、次のような機能も備えている。

―テストスクリプトの構造化（条件分岐、他のテストスクリプトの呼び出し等）

―テスト実行のスケジューリング―リグレッションテストの自動化―Mercury Business Process Testingとの連携によるERPの業務アプリケーションテストの自動化



6.2 主なＧＵＩテスト支援ツール（続き）５） twist: Web, Javaアプリケーション向けの総合テスト支援ツールで下記の特徴を持つ。twistは、ThoughtWorks社の製品である。a) テストシナリオを Groovy と呼ばれる動的スクリプト言語で記述し、

DSL(Domain Specific Language）相当の表現を可能にしている。これによりテストを記述し易く、理解し易くしている。

b) テーブルドリブンでのテスト記述、実行を可能としてる。c) Hybrid Execution機能により、手動と自動の混在モードのテストが実行出来る。

d) Seleniumなどの他のツールとの連動を可能とするアダプタを具備している。

e) 現時点では、日本語化されていない。



6.2 主なＧＵＩテスト支援ツール（続き）６） Solex: Solexは、Webサーバとブラウザーの間に設置されたプロキシサーバとして振る舞うことでHTTPセッションを記録し、再生する。これを利用してWebApの機能テストを行うことが出来る。主な機能は以下のとおりである。

a) HTTPセッションを記録する：プロキシサーバとして振る舞うことにより、WebブラウザとWebサーバ間を行き来するHTTP requestとHTTP responseをHTTPセッションとして記録する。

b) 記録したHTTPセッションを再生する：上述の記録したHTTPセッションを後で再生して、Web機能の回帰テストに利用する。

c) HTTP requestをカスタマイズして再生する：上述の記録したHTTP

requestをカスタマイズした上で再生することが出来る。d) HTTP responseを検証する：そして、再生時には、HTTP

responseに対してユーザーの規定する検証を行うことが出来る。



6.2 主なＧＵＩテスト支援ツール（続き）７）Worklight: Worklight は、IBM社が提供するモバイルソフトウェア開発環境である。２０１２年にイスラエルのWorklight 社を買収し、その技術を製品化したもので、買収後も積極的な機能拡張を推進しIBM社ソフトウェアの重要なセールスポイントとしている。

Worklightは、Eclipse環境の上に構築されており、総合的なソフトウェア開発環境を提供している。再テストの自動化機能も充実しており、各種のスマートフォン、タブレット端末のテストが自動実行出来るようになっている。


７．Selenium

7.1 Seleniumの役割Seleniumは、WebApのテスト自動化支援システムである。Webブラウザを実行させるための、スクリプトあるいはAPIを記述し、それを実行させることが出来る。このことにより、手間をかけて手動で実行していたWebApのテストを自動化することが出来る。

Seleniumは、当初、JavaScript, HTML, iFrame(inline Frame)を用いて実現された。このために、極めて広範囲のOS, Windowシステムに適用可能になった。

Selenium Coreは、当初はThoughtWorks 社の社内ツールとして開発され、利用されていたが、これが２００４年にオープンソース化されて誰でもが使えるようになった。また、オープンコミュニティーの力により、Seleniumファミリーとして機能的にも大きな追加・改善が加えられ、今日の隆盛を迎えている。特に、２０１１年、Google社が開発したWebDriverを統合したSelenium2の提供により大幅に機能強化された。


7.2 Seleniumの発展経緯１）２００４年、ThoughtWorksのJason Hugginsが

JavaScriptTestRunnerの名でSeleniumのベースを開発。２）これがThoughtWorks社内の同僚の間で評判になり、社内で拡張されるとともに、さらにユーザを広げるためにオープンソース化された。３）Bea(後にOracleが買収）のDan FabulichとNelson Sproulが、

Selenium RCを開発。４）２００６年、日本のAppirits社の笠谷が、Selenium IDEを開発。５）２００７年、 Jason Hugginsは、Googleに移り、そこでSelenium RC

を拡張し、Selenium Gridを開発。６）２０１１年、SeleniumとGoogle社が開発したWebDriverを統合した

Selenium2が提供開始された。WebDriverは、Seleniumと同様な機能を持ちながら、より使い易いAPIを持っている。この統合化によりSeleniumの普及が加速化された。Selenium2は、ブラウザとして、Firefox, Chrome, IE, iPhone, Android, Operaをサポートしている。

７．Selenium


7.3 Seleniumの構成Seleniumは、次の４つのコンポーネントから構成されている。１） Selenium Core

Seleniumの中核機能コンポーネントである。２） Selenium Remote Control

リモートサーバ対応機能および言語対応テスト機能を提供している。当コンポーネントは、Selenium Grid（並列サーバ機能）へも発展した。Selenium GridによりGUIテストを並列化、高速化できる。

３） Selenium IDE

Seleniumを活用するためのIDE(Integrated Development

Environment:開発支援環境）。具体的には、ブラウザの操作を自動的に記録して、それに基づくテストコードの自動生成する。したがって、再テストが自動化される。

４） Selenium on Rails:

Ruby on Railsで、Seleniumを使うためのコンポーネントである。

７．Selenium


７．Selenium

7.4 Selenium Core

Selenium Coreは、JavaScriptにより実現されており、各種Webブラウザを操作するためのコマンドを提供する。1） Seleniumのコマンド種別

Seleniumでは、コマンドによりWebブラウザを操作したり、Webブラウザに表示されている内容を検証したりすることが出来る。コマンドは、次の３種類がある。

a) Actionコマンド「指定したURLを開く」、「フォームに入力する」、「ボタンやリンクをクリックする」、のように、Webブラウザを操作する。このコマンドの例を以下にあげる。－open

－type

－click

－addSelection


７．Selenium

7.4 Selenium Core（続き）1） Seleniumのコマンド種別（続き）

b) Assertion コマンドこのコマンドには二つの機能がある。一つは、ページタイトルやWebに表示された内容を検証するもので、assert~, verify~があり、検証結果がNGの場合に、assert~ではテストを中止、verify~ではテストを続行する。もう一つは、指定した条件が満たされるまで動作を待つもので、waitFor~の名称を持つ。

以下、このコマンドの例を示す。－assertTitle

－verifyTextPresent

－verifyTable

－assertConfirmation

－wait ForVisible


７．Selenium

7.4 Selenium Core（続き）1） Seleniumのコマンド種別（続き）

c) Accessorコマンドそのページ内の指定した要素について値を取得して変数にセットする。Seleniumの内部処理的には、Assertionコマンドは、Accessor

コマンドをベースに作られている。

このコマンドの例は次の通り。－storeTable

－storeText

－storeValue


７．Selenium

7.4 Selenium Core（続き）2） Seleniumコマンドの記述形式

Seleniumコマンドの記述形式は次のようになっている。

コマンド名第一引数（ターゲット）第２引数（バリュー）

第一引数は対象（ターゲット）となるHTML要素を示し、第２引数は入力したり、検証する値（バリュー）を示す。

HTMLでテストコードを記述する場合は、上記の記述形式に従って、一行３カラムのtable形式で、複数のコマンドを複数行のテーブルとして記述することが出来る。HTMLでの記述は、ユーザにも理解出来て、ソフトウェアの内部の実現方式に依存しない。しかし、共通部分の共有等の高度の利用が出来ない（共通部分の共有のためには、次に述べるSelenium RCを用いる必要がある）。


７．Selenium

7.5 Selenium RC

Selenium RC(Remote Control)は、① リモートサーバにアクセスしてテストを行う② 開発言語でテストを作成し、実行する

の二つの機能を持つ。

Seleniumコマンドによりテストを実行する方法については、既に7.4

で述べた。Selenium RCを用いて、開発言語でテストを作成すれば、繰り返し使われる機能等は共通メソッドとして作成して、必要時に呼び出す、と言ったより高度なことが出来る。そして、その開発言語に備わっているテスト支援機能と組み合わせての活用も出来る。

Selenium RCは、Java, C#, Ruby, PHP, Perl, Python

等、多様な開発言語に対応している。Javaの場合は、単体テスト支援ツールJUnitと組み合わせて利用することも出来る。


７．Selenium

7.6 Selenium IDE

Selenium IDEは、① ブレイクポイントの設定が可能なデバッグ支援機能② Web操作の記録機能③ 上記②によるテストコードの自動生成機能

等を実現している。Selenium IDEの開発者は、日本のAppirits社の笠谷氏であり、日本語にも対応している。上記の③の機能では、HTML形式のSeleniumコマンドの他に、各開発言語対応のテストコードを生成する。したがって、最初に手作業でテストした後は、２回目からは、生成したコードを使って自動リグレッションテストが実行出来る。また、いちいちテストコードを自分で記述する手間が省ける。しかしながら、生成されたテストコードが正しいか、また、共通化等の改善の必要性が無いか、の確認が必要である。



8.1 Selenium2

Google社のSimon Stewart は、Web GUIのテスト自動化支援を目的としたWebDriverを開発した。２０１１年にリリースされたSelenium2

は、Seleniumの特徴を継承しつつWebDriverの良さを取り込んでいる。Selenium + WebDriver = Selenium2

Selenium 2 は WebDriver の簡潔なオブジェクト指向の API を継承し、ブラウザーとのやりとりは、そのブラウザーに最善の方法で行うようになっていて、テストプログラムが書きやすくなっている。また、Selenium2は、Seleniumの機能を包含していて、Seleniumで作成したテストデータをSelenium2向けに簡単に変換・移行できるようにしてある。

Selenium2が提供開始され始めてから５年が経過しつつあるが、人々が受け入れたのはSelenium2全体ではなく、WebDriverの機能であった。Selenium2全体ではなく、Selenium WebDriverあるいは単にWebDriverの名でWebDriver機能だけが取り出されることが多い。



8.2 WebDriverとSelenium RCの相違WebDriverとSelenium RCは次の点で異なっている。１）WebDriverは、オブジェクト指向でプログラミングされており、プログラマーにとって使い易いものになっている。一方、Selenium RCは、Selenium Coreのコマンドを列挙するものであり、柔軟性にかけ、機能的にも制約がある。２）WebDriverは、各ブラウザごとの個別のドライバーと連動する。したがって、スマートフォンにも対応出来る。Selenium RCは、スマートフォンには対応できない。３）WebDriverは、極めて高度なWebインターラクション機能を提供している。４）WebDriverは、ブラウザーの操作とブラウザー上の情報の取得に機能を絞っている。Selenium Core/RCが持っているテスト用の機能はない。テスト用の機能は、JUnit, TestNGのようなテスト支援ツールの助けを借りなければならない。



8.3 WebDriverによるWebElementの指定と操作Webページは、ボタン、リンク、ボディ、ラベル、フォームなどの様々なHTML要素から構成されている。WebDriverでは、これらをWebElementと呼んでいる。

対象とするWebElementを探すためには、findElement あるいはfindElementsメソッドを使う。そして探すためのキイワードを、Byメソッドで指定する。指定方法としては、Name, ID, TagName, Class,

LinkText, PartialLinkText, Xpath, CSSの８種類がある。

次にWebElement上での操作を指定するためには、表8.1に示すような操作がある。指定できる操作は、WebElementの種別ごとに異なっている。誤った操作を指定すると、WebDriverは、エラーメッセージや例外操作をすることなく、単に無視する。



8.3 WebDriverによるWebElementの指定と操作（続き）

項番操作メソッド対象WebElement 機能

１ getAttribute 全てのWebElement 属性を取得

２ sendKeys テキストテキストを入力

３ clear テキストテキストを消去

４ submit フォームフォームをWebサーバへ送信

５ getCssValue 全てのWebElement CSSの属性値を取得

６ getLocation 全てのWebElement 描画されている相対的な位置を取得

７ getSize 全てのWebElement WebElementの幅と高さを取得

８ getText 全てのWebElement 表示されているテキストを返す

９ getTagName 全てのWebElement WebElementのタグ名を返す

１０ isDisplayed 全てのWebElement この要素が表示されているか調べる

１１ isEnabled 全てのWebElement この要素が有効であるかを調べる

１２ isSelected ラジオボタン他この要素が選択されているか調べる

表8.1 WebElement に対する操作の指定



8.4 WebDriverの高度な操作前節8.3では、WebDriverの基本的な操作について述べたが、さらに次のような高度な操作もWebDriverで実現できる。１）複数のアクションの合成複数のアクションを同時に行う（例えば、複数キイの同時押下）ためにはActionsクラスを用いて、次のプロセスを実行する。① 複数のアクションをActionsクラスを用いてグループ化する② この合成されたアクションをbuildする③ 合成されたアクションをperformする

２）マウスベースの操作マウスベースの操作を表8.2に示す。

３）キーボードベースの操作キーボードの操作を表8.3に示す。



8.4 WebDriverの高度な操作（続き）

項番アクション名説明

１ moveByOffset マウスを現在の位置から別の位置へ移動させる

２現在の位置でclick 現在の位置でマウスを右クリック

３ WebElementに対するclick WebElementのnameやid を指定してクリック

４現在の位置でのclickAndHold 現位置でマウスを左クリックしてそのまま保持

５ WebElementのclickAndHold WebElementを指定して、マウスを左クリック、保持

６ release マウスの左ボタンをリリース

７他のWebElement上でrelease 保持しているWebElementを他のWebElement上でrelease

８ miveToElement マウスカーソルを特定のWebElementに移動

９ dragAndDropBy 指定したWebElementをドラッグアンドドロップ、移動する水平方向、垂直方向のオフセットを指定

表8.2.1 マウスベースの操作（１）



8.4 WebDriverの高度な操作（続き）

表8.2.2 マウスベースの操作（２）


１０ dragAndDrop 指定したWebElementを他の指定したWebElementのところまでドラッグアンドドロップ

１１現在の位置でのdoubleClick カーソルの現在の位置でのダブルクリック

１２ WebElement上でのdoubleClick 指定したWebElement上でのダブルクリック

１３現在の位置でのcotextClick カーソルの現在の位置での右クリック

１４ WebElement上でのcotextClick 指定したWebElement上での右クリック


１ KeyDown Shift, Ctrl, Alt キーを押下して、保持する

２ KeyUp KeyDownされたキーをリリースする

３ sendKeys 文字のキーをWebElementに入力する

表8.3 キーボードの操作



8.5 WebDriverのその他の機能以上、8.3, 8.4では、WebElementに対する基本操作と高度な操作

について述べてきた。以下、本節では個々のWebElementに限定しないWebDriver全体にかかわる機能を説明する。１）ブラウザーの機能の設定ブラウザーの機能はブラウザー間で共通のものと個別のものとがある。複数のブラウザー間で共通の機能としては、表8.4に示すようなものがある。これらの機能はWebDriverのインスタンスの生成時にDesiredCapabilitiesクラスのインスタンスを生成して設定する。２）スクリーンショットの取得スクリーンショットの取得はテスト、その他の作業に於いて極めて大切なものである。形式は、BASE64, BYTES（生のデータ）,FILEの３種類が指定できる。スクリーンショットの範囲はブラウザーにより異なり、①ページ全体 ②現在のウィンドウ ③現在のフレームの表示されている部分 ④ディスプレイ全体のいずれかになる。



8.5 WebDriverのその他の機能（続き）

項番機能説明

１ takeScreenShot Wenページのスクリーンショットを取れるかどうか

２ handlesAlert モーダルダイアログを扱えるかどうか

３ cssSelectorsEnabled 要素の検索でCSSのセレクターを使えるかどうか

４ javascriptEnabled ユーザーが提供したJavaScriptの有効化/無効化

５ acceptSSLCerts デフォルトですべてのSSL証明書を受け付けるかどうか

６ webStorageEnabled HTML5の機能で、ストレージオブジェクトの扱いを有効化、無効化出来る

表3.4 ブラウザーの機能の設定



8.5 WebDriverのその他の機能（続き）３）ターゲットウィンドウとフレームの指定

WebDriverを用いて複数のウィンドウ間、フレーム間の切り替えることが出来る。①ウィンドウ間の切り替え

switchTo().windowメソッドにより切り替える②フレーム間の切り替え

switchTo().frameメソッドにより切り替える③アラートの処理

Webアプリケーションの中で様々なモーダルダイアログを扱う必要がある。そのためのアラートダイアログを扱うためのAPIとして表3.5に示すものが用意されている。



8.5 WebDriverのその他の機能（続き）

項番 API 機能

１ void accept() OKボタンに対応するアクションが呼ばれる

２ void dismiss() CANCELボタンに対応するアクションが呼ばれる

３ java.lang.String getText() ダイアログ上に表示されているテキストを返す。

モーダルダイアログ上のテキストを評価したい場合に用いる。

４ void sendKeys(java.lang.Stringkeys ToSend)

アラートがテキス入力を受付けるようになっている場合に、テキストを入力する

表3.5 アラートダイアログに対するAPI



8.5 WebDriverのその他の機能（続き）４）ナビゲーション

WebDriverは、ブラウザーの検索履歴に沿って、ナビゲーションを成業する機能を持っている。次のような機能から構成される。①driver.navigate().back()

ブラウザーの戻るボタンをエミュレートして、前の画面に戻る②driver.navigate().forward()

ブラウザーの履歴に沿って次の画面に進む③driver.navigate().refresh()

現在のURLをリロードしてリフレッシュする。F5キーエミュレートする。④driver.navigate().to(url)

指定したURLの画面に移動する



8.5 WebDriverのその他の機能（続き）５）WebElement群のロードの待機ネットワークの遅延時間その他の理由で対象とするWebElement

群がロードされず、必要なテストが出来ない場合がある。WebDriver

では、そのための待ち時間を指定できる。指定の方法は２種類ある。「暗黙の待ち時間」では、対象とするアプリケーション全体に対して均一な待ち時間を指定する。「明示的な待ち時間」では、特定の条件下における待ち時間を指定する。

６）クッキーの利用あるアプリケーションから、他のアプリケーションを起動して連携する場合にそのたびにログインすることに時間を費やすことは避けたい。ログインのための情報をクッキーに保存、再活用して、これを改善するような処理をWebDriverを用いて指定することが出来る。



8.6 WebDriverがサポートするブラウザーWebDriverでは、次のようなブラウザーをサポートしている。各ブラウザー対応のDriverを起動して、それぞれに固有な機能、インタフェースの相違を吸収している。① Firefox

② InternetExplorer

③ Chrome

④ Safari

⑤ Opera



8.7 PageObject パターンPageObjectパターンとは、アプリケーションの画面を一つのオブジェクトと捉えるデザインパターンである。WebDriverの利用に当たっては、PageObjectの活用が次のような効果をもたらす。（参考文献８））① 画面内部（配置情報等）にアクセスするコードとこれを外から利用するテスト用のコードとを完全に分離する。画面内部にアクセスするコードによりPageクラスを実現する。外からこの画面にアクセスする場合はこのPageクラスだけを用いてアクセスする。

② 画面に関するコードがばらばらに分散配置されずに一か所に集中管理される。

すなわち、PageObjectは、画面を仮想化し、画面の外からの画面へのアクセスをサービス化する。これにより画面固有の内部の変更が外部のサービスに影響しないようにする。そして画面機能の再利用を容易にし、そのソフトウェアの保守性を優れたものにする。


９．BDDとJBehave

9.1 BDDが求められる背景BDD(Behavior Driven Development)は、顧客が求める動作要求

(Behavior)に基づき、ソフトウェアを開発しよう、とする開発技法である。このBDDが求められてきた背景として次の二つがあげられる。① TDDへの批判、改善要求（4.8 TDDの課題を参照）② 顧客要求を顧客にも理解できる形式で記述し、それに基づきテストをしたい、との基本的要請への対応

BDDという言葉は、上記①を意識したもので、TDDの利点を取り込み、欠点を改善しようとの考え方に基づく。一方、②は、古くから現在に至るまで継続的に追及されてきたテーマであり、その実現方式が多様な形態で発展してきた。現代的には、DSL(Domain Specific Language)と表現されることが多い。

BDDとDSLは、表現形式は異なるが考え方に共通する部分が多い。BDDのBehavior = DSLのDomain Specification ＋テストシナリオと捉えられる。


９．BDDとJBehave

9.2 BDDの考え方BDD(Behavior Driven Development)は、4.8に述べたTDDに対する批判に基づいて生まれた開発技法である。１） BDD: BDDは、顧客他(Stakeholders)の観点からの振る舞い

(Behavior)の記述に基づくソフトウェアの開発技法である。Behaviorを先に記述し、それに基づきコードを書き、テストを実行する。

２） BDDの３原則a) It’s all behavior: コードレベルであっても、アプリケーションレベルであっても、どのような粒度であっても、常に振る舞い（behavior ）の観点で考える。

b) Deliver Stakeholder value: 顧客等関与者にとって価値のあるものを開発、提供する。それ以外のものは開発、提供しない。

c) Enough is enough: やるべきことはきちんとやる。しかし、それ以上の無駄なことはやらない。浪費になる。


9.3 TDD 対 BDD

Dan Northは、TDDの考え方を発展させて、BDD (Behavior Driven

Development)を提案した。BDDでは、考えかたを徹底するために用語体系から変更している。

<TDD> <BDD>

テストクラス振る舞い(Behavior)

テストケース実行可能サンプル(example)

アサート(assert) 期待する振舞(expectation)

すなわち、BDDでは、仕様＝実行可能仕様＝テスト仕様であり、DSLによる記述を前提としている。別の言い方をすれば、TDDは内部仕様ベースのテスト、BDDは外部仕様ベースのテストを前提としている。ＴＤＤは、単体テストの自動化手段として発展してきた。近年、GUIベースのテスト、クラウドベースの運用テストに比重が増すとともにBDDへの関心が高まってきた。

９．BDDとJBehave


９．BDDとJBehave

9.4 BDDの歴史以下ではBDDの歴史の中を辿ってみることとしよう。１） TDD用テストフレームワークxUnitとその後継

xUnitは、TDD用のテストフレームワークであり、そのJava版がJUnit, Ruby版がRUnitである。そして、RUnitは現在では、Test::Unitに引き継がれている。

２） JBehave

Dan North は、BDDの研究を進め、２００３年にJUnit を置き換えるものとして、BDD用のテストフレームワークJBehave を開発した。JBehaveは、当初は実験的なものであったが、その後、改良が続けられ現在でも利用されている。また、その後に開発された多くのBDDツールに影響を与えた。(Dan Northは、当時、ThoughtWorks

社に所属していた。）近年では、Javaベースの開発でのGUIテスト、システム運用テストの自動化の手段としてJBehaveが見直され、新たな改良が加えられるようになってきている。


９．BDDとJBehave

9.4 BDDの歴史３） RSpec

RSpecは、Ruby用のTest::Unitを置き換えるものとして、２００５年に Steven Baker により開発された。RSpecは、BDD向けの単体テストフレームワークであり、その考え方は、先行する JBehave を参考としている。RSpecは、現在、Ruby向けに広く活用されている。

４） RSpec Story Runner

Dan North は、JBehave のRuby版 RBehaveを開発し、更にはRSpecとマージして、RSpec Story Runner とした。

５） Cucumber

２００８年に、Aslak Hellesoyは、RSpec Story Runnerを文法的に整理して書き直し、Cucumber と名付けた。当初は、RSpecに統合する予定であったが、独自の地位を占めるようになった。Cucumberは、単体テストに限らず、機能テストを含めた広い範囲のテストに使える。


９．BDDとJBehave

9.5 BDD支援ツールJBehaveの特徴JBehave は、自然言語に近い特定の形式で書かれたシステムの振る舞いをテストとして実行するBDDに基づくフレームワークである。

JBehaveの基本的な特徴は次の通りである。１）記述した振る舞いは、ユーザ、企画者、業務担当者等のプログラマ以外の人々にも理解が出来る。したがって、関与者間の合意が取れた内容の開発、テストが出来る。

２） Javaで記述されたBDD用のDSLである。３）開発、テストの対象となるソフトウェアは、Javaで記述されるプログラムである。

４）開発とテストが一体化して進められる。これにより、総合的な作業効率の向上が図れる。また、その後の保守作業の効率向上が期待出来る。


９．BDDとJBehave

9.6 JBehaveによる開発の手順以下に、JBehaveによる開発の手順を５Stepに分けて説明する。

Step1：ストーリー（仕様）をJBehaveのGherkin形式で記述する。（Gherkin形式は自然言語に極めて近い）

Step2：ストーリーの各ステップをJavaにマッピングする。（JBehaveのアノテーション@を用いてマッピング）

Step3：上記をJava実行形式に変換する。（JBehaveの実行フレームワークであるEmbedderをもちいる。

Embedderとしては複数のものの中から選択できる。）Step4：実行する。Step5：レポートを作成、参照する。


９．BDDとJBehave

9.6 JBehaveによる開発の手順（続き）

図9.1.1 ストーリーの記述


９．BDDとJBehave

9.6 JBehaveによる開発の手順（続き）

図9.1.2 ストーリーの各ステップをJavaにマッピング


９．BDDとJBehave

9.6 Jbehaveによる開発の手順（続き）

図9.1.3 Java実行形式に変換


９．BDDとJBehave

9.6 Jbehaveによる開発の手順

図9.1.4 プログラムを実行図9.1.5 レポート参照


９．BDDとJBehave

9.6 JBehaveの構造9.6.1 JBehaveにおける Story の構造

JBehaveにおいては、一つの Story（説明）は、次の要素から構成される。＜Storyの構造＞－A title: 標題－A narrative: 説明記述

① feature: 仕様② benefit: 目的、期待する効果③ stakeholder: 関与者（ユーザ、企画者、運用者等）

－A acceptance criteria: Storyが成り立つためのシナリオ① given: どんな条件が成り立つ場合に② when: 何がおきたら（どんな入力、イベントがあると）③ then: どのような結果、出力が期待できるか


９．BDDとJBehave

9.6 JBehaveの構造9.6.2 Gherkin の構造

JBehaveの仕様を記述する言語Gherkinでは、先頭のキイワードのみを規定し、後の文章は自由形式になっている。１）Gherkinは、次の階層構造を持つ。－feature (with story)

－scenario

－step

すなわち、featureは複数のscenarioを含み、scenarioは複数のstep

を含む。２）featureには、実現されるべき仕様をまず一行で記述する。そして、そのあとには、story として、誰を対象として（stakeholder), どんな機能(feature)を、なにを目的として(benefit)いるかを記述する。３） scenarioによりfeatureを形作る要素機能としてのテストシナリオを記述する。複数のstepで実現される。


９．BDDとJBehave

9.6 JBehaveの構造9.6.2 Gherkin の構造（続き）

４） stepでテストシナリオの操作や検証のためのステップを記述する。そして、step definition file にあるテスト対象プログラムを実行する。

各step の先頭には次の予約語が使われる。－given（前提）：データのセットアップ等テストシナリオの

前提条件を記述するステップ－when（もし）：判定条件を記述するステップ－then（ならば）：結果を検証するステップ－and(かつ）：すぐ上のステップと同じ役割のステップ－but（しかし）：すぐ上のステップと同じ役割のステップ


９．BDDとJBehave

9.7 JBehaveとWebDriver

JBehave Webは、JBehaveとSeleniumを統合する。具体的には、JBehaveで定義されたStepをSeleniumのAPI群に対応付ける。ここでSeleniumのＡＰＩ群としては、Selenium1互換のものと、WebDriverのものとが選択可能である。どちらでも利用可能であれば、WebDriver APIの方がオブジェクト指向で利用可能であるからはるかに有利である。オブジェクト指向を利用して高度のＡＰＩを実現できる。この場合に、前述したPageObjectパターンを活用するべきである。Page内部の物理的な構造をPageObjectの中に隠ぺいして、Page外部からのアクセスは業務ベースの用語に基づくAPIでアクセスすることが望ましい。

JBehaveのStepは、ユーザー業務との対応がつく表現を可能としている。上記のWebDriverにより実現されたPageObjectは、JBehaveのStepとの対応付けがとり易い。


１）「現場で使えるソフトウェアテスト Java編」町田欣史、高橋和也、小堀一雄、飯山教史２００８年翔泳社

２） “The ThoughtWorks Anthology-Essays on Software Technology and

Innovation” R. Singham, M. Fowler, et al. 2005 by O’Reilly

「ThoughtWorksアンソロジー」（訳）オージス総研２００８年オライリー・ジャパン

３） “Agile Testing: A Practical Guide for Testers and Agile Teams” L. Crispin,

J. Gregory 2009 by Pearson Education, Inc. 「実践アジャイルテスト：テスターとアジャイルチームのための実践ガイド」（訳）榊原彰他翔泳社

４） “The RSpec Book: Behavior-Driven Development with RSpec, Cucumber,

and Friends” David Chelimsky 2010 The Pragmatic Bookshelf

５）「はじめる！ Cucumber」諸橋恭介２０１０．１２．０９版達人出版会（電子ブック）

６） Cucumberのblogから転載： http://blog.geekdaily.org/2009/06/cucumber-

webrat-who-names-these-things.html

７） JBehave Official Site: http://jbehave.org/

８） Selenium Official Site: http://www.seleniumhq.org/

＜以上＞

http://blog.geekdaily.org/2009/06/cucumber-webrat-who-names-these-things.html

http://jbehave.org/

http://www.seleniumhq.org/