Fitnesse を用いたテストの効率化について

第一回デジタルエンタメ研究会 ( 仮 ) 2011-04-23HN:cac+

1. Fitnesse とは 2. Fitnesse デモ 3. 展望 4. まとめ 5. 質疑応答

あじぇんだ的な何か

1. Fitnesse とは…… の前に

BDDって知ってますか？

BDD = Behavior Driven Development 日本語では「振舞駆動開発」

ざっくり説明すると……要求仕様を満たしているかどうかのテスト ( コー

ド ) を先に作成し、プログラミングを行う手法。

BDD とは

TDD(=Test Driven Development)プログラムの動作を保障するテストを ( 先に ) 作成する。テストケースの作成はテスト実行者の経験に委ねられる ( 事が

多い ) 。テスト工数が肥大化しがち。

BDD( 要求 ) 仕様に従った形でテストを作成する。テストケースの作成が明快である。不必要なテストケースを作成するのを抑える事ができる。

TDD と何が違うの？

BDD は肥大化する開発規模とテストにおける解法の一つである……かも？

前振りが長くなりましたが……

1. Fitnesse とは

Fit を Wiki 形式の表で自動テスト駆動するように拡張した Java 製のテスト補助エンジン (+ フレームワーク )

BDD にとっても向いてる

対応言語は Java 、 C# 、 C/C++ etc...

Web サーバの機能を持ち Wiki としても利用可能 Wiki の表形式記法をベースにテストケースを作成可 プラグインによる拡張で blog 機能も持たせられるら

しい

Fitnesse ってなんぞ

※Fi ｔ → HTML のテーブル形式でテストケースを作成可能な補助エンジン

Fitnesse の構成

Fitnesse

連携用フレームワーク

Wiki形式で記載されたテストケースを独自のデータに変換して実際のテストフレームワークに渡す

テスト実行者Wikiの表形式でテストケースを記載する

受け取ったテストケースを元にテストを実行し、その結果を返す

Wikiの表形式でテスト結果を表示する

Fitnesse はあくまで Wiki の表形式によるテストケース

を独自の形式に変換するツールなので、実際にテスト

を実行するコードに対するフレームワークが必要 言語毎に連携させるフレームワークは異なる C/C++ では「 cslim 」 Java では「 FitSharp 」 フレームワークは自作も可能 → 例えば、 Google Test をベースに作成すると

か

連携用フレームワークについて

仕様作成者 or テスト実行者Wiki の表形式ベースでテストケース ( テストパラメータ ) を作成す

る

プログラマーCslim 等の連携用フレームワーク を用いてテストケースの雛形を作成

する

結局、何をすればいいの？

役割分担が明確！

でも、使い辛いんでしょ？それじゃあ意味がない！！

2. Fitnesse デモ

環境： Visual Studio2010(Windows) 簡易的な仕様書を作成し、それをそのままテスト

ケースとして稼動させる例を実装する …… 予定でしたが、時間が無かったのでデフォル

トに用意してあるプロジェクトを見ていく事に

実際に見てみよう

Wiki の表形式で作成したテスト ( ケース ) の自動実行

過去のテスト結果を自動で記録

テストケースのリファクタリング

テスト結果や Wiki ページの検索

Fitnesse で出来る事まとめ

連携用フレームワークを用いた専用のテストプログラムの作成が必須なので、習熟しているテストフレームワークからの乗り換え ( 学習 ) コストが掛かる

欠点 1 : システム構築者の負担が重い

誰かが犠牲になって既存のフレームワークと互換の取れるフレームワークラッパを作るとプロジェクト全体が幸せになれる ( ﾎﾞｿｯcppunit や Google Test を利用している場合ならそこまで手間無しにラッピングできるかも ( 検証中 )

仕様がテストケースに成り得るのが Fitnesse の持ち味なのに、その仕様が既に存在していると……

更に、使用しているテストプログラムの書き換えが発生するとなると採用に二の足を踏まれ易い

テスト履歴の視認性アップや管理性の向上の恩恵は受けられる

導入する事によりテストケースの見直しを行える効果はあるかもしれない

欠点 2 : 既存のプロジェクトへの効果が薄い

UI が英語当然ヘルプも英語国内での採用事例もほとんどないので、参考資料

もほぼ全部英語

欠点 3 : 英語ｪ……

3. 展望

仕様とテストケース ( パラメータ ) の結合が可能 テスト作成工数の減少 テストプログラムのメンテ軽量化 テスト結果の可視化、共有化が容易 テスト結果の保持、比較が容易 テストの流れが明快になる

Fittnese 導入によるメリット

仕様書を Fitnesse にそのまま食わせる事が可能な Wiki の表形式で作成する事で、 テスト実行者 ( 実装者 ) が仕様を勘違いしていてテスト

になっていなかった 仕様変更の度にテストプログラムを書き換える必要があ

り、そこでエンバグを引き起こしてしまったという残念だが「良くある」事態を防ぐ事ができる。

仕様とテストケース ( パラメータ ) の結合が可能

個人的に Fitnesse 導入の最大のメリットはこれ !

便利なんだけどデータをテスト用に変換するのがめんどくさい各種テーブル等も気軽に利用可能になる

→ 例 : ディシジョンテーブル

テスト作成工数の減少

Web サーバ形式なので、チームの共有サーバに設置すれば気軽に全ての人員がテスト結果を参照可能

テスト結果だけでなく、テストケースも気楽に参照可能

テスト結果の可視化、共有化が容易

プログラム作成者はテストの雛形までを作成 テスト実行者がテストケース ( パラメータ ) を作

成 テストはデイリーで自動実行という流れを構築できる。

分業の範囲も明確になる若干プログラム作成者のコストが高めになるかも

テストの流れが明快になる

自動化の推進Jenkins や Sikuli といったツールと組み合わせる事によりシステムテストの自動化まで持っていきたい

連携用フレームワーク (clism) の改造GoogleTest ばりにテスト用マクロを充実させたりしてみると採用への足掛かりになるかも？

Fitnesse 展望

Jenkins については粉川先生の CEDEC の講演を参考に！CEDiL で無料で見れますhttp://cedil.cesa.or.jp/

BDD を採用すると無駄なテストを減らした上にテストの品質を向上できる！ ……かも

まとめ

Fitnesse を採用すると BDD 的な、仕様とテストケースが一体化した開発を行う事ができる！……かもつまり、 Fitnesse を採用すればテスト工程の効率化を図れ、メインのアプリ開発に注力できる！……ﾄｲｲﾅ

BDD って便利そうだけど……

詳細な仕様が決まってないと 実装できないじゃん！ゲーム開発でそれはありえない！

Pre FAQ

仕様先行が本来あるべき姿ゲーム業界にはよくある事、と仕様検討無しで実

装を 開始し、後で修正……という悪習から脱却する機

会 にもなりうる ただし、全てのプロジェクトに採用すれば上手く

回る、 という訳ではない。基幹系は向いてるけど、試行錯誤

前提のゲームシステム部には向いてないかもしれな

い。よく考えて採用するのが大事。

その考え方が悲劇を生むのです バ グ

Cslim 導入http://schuchert.wikispaces.com/cpptraining.GettingStartedWithFitNesseInCpp

Java/C# での Fitnesse 導入資料http://www.jasst.jp/archives/jasst05e/pdf/S5-B-1.pdf

TDD,BDD,SDD,ATDD についての話題http://togetter.com/li/4220

Fitnesse公式http://www.fitnesse.org/FrontPage

参考文献・サイト