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

1Copyright (C) Masanori Kataoka, All Rights Reserved.
Testing Framework(TDDとBDD)
～JUnit, JBehave, SeleniumWebDriver～
２０１５年１２月８日
片岡雅憲
2015/12/11
1
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、メモリ等）の使用状況の分析

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) 現時点では、日本語化されていない。

６） 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に対してユーザーの規定する検証を行うことが出来る。

７）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
1） Seleniumのコマンド種別（続き）
c) Accessorコマンド
そのページ内の指定した要素について値を取得して変数にセットす
る。Seleniumの内部処理的には、Assertionコマンドは、Accessor
コマンドをベースに作られている。
このコマンドの例は次の通り。
－storeTable
－storeText
－storeValue

７．Selenium
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 ブラウザーの機能の設定

３）ターゲットウィンドウとフレームの指定
WebDriverを用いて複数のウィンドウ間、フレーム間の切り替える
ことが出来る。
①ウィンドウ間の切り替え
switchTo().windowメソッドにより切り替える
②フレーム間の切り替え
switchTo().frameメソッドにより切り替える
③アラートの処理
Webアプリケーションの中で様々なモーダルダイアログを扱う必
要がある。そのためのアラートダイアログを扱うためのAPIとして
表3.5に示すものが用意されている。

項番 API 機能
１ void accept() OKボタンに対応するアクションが呼ばれる
２ void dismiss() CANCELボタンに対応するアクションが呼ばれる
３ java.lang.String getText() ダイアログ上に表示されているテキストを返す。
モーダルダイアログ上のテキストを評価したい場合
に用いる。
４ void sendKeys(java.lang.String
keys ToSend)
アラートがテキス入力を受付けるようになっている
場合に、テキストを入力する
表3.5 アラートダイアログに対するAPI

４）ナビゲーション
WebDriverは、ブラウザーの検索履歴に沿って、ナビゲーションを
成業する機能を持っている。次のような機能から構成される。
①driver.navigate().back()
ブラウザーの戻るボタンをエミュレートして、前の画面に戻る
②driver.navigate().forward()
ブラウザーの履歴に沿って次の画面に進む
③driver.navigate().refresh()
現在のURLをリロードしてリフレッシュする。F5キーエミュレート
する。
④driver.navigate().to(url)
指定したURLの画面に移動する

５）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.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.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/
＜以上＞

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

More Related Content

Similar to Agileツール適合化分科会（tddとbdd）

More from masanori kataoka

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