1. Fitnesseを用いたテストの効率化について 第一回デジタルエンタメ研究会(仮)2011-04-23 HN:cac+

2. 1.Fitnesse とは 2.Fitnesse デモ 3. 展望 4. まとめ 5. 質疑応答 あじぇんだ的な何か

3. 1.Fitnesse とは ……の前に

4. BDD って知ってますか？

5. BDD = Behavior Driven Development 日本語では「振舞駆動開発」 ざっくり説明すると…… 要求仕様を満たしているかどうかのテスト(コード)を先 に作成し、プログラミングを行う手法。 BDDとは

6. TDD(=Test Driven Development) プログラムの動作を保障するテストを(先に)作成する。 テストケースの作成はテスト実行者の経験に委ねられる(事が多い)。 テスト工数が肥大化しがち。 BDD (要求)仕様に従った形でテストを作成する。 テストケースの作成が明快である。 不必要なテストケースを作成するのを抑える事ができる。 TDDと何が違うの？

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

8. 前振りが長くなりましたが…… 1.Fitnesse とは

9. FitをWiki形式の表で自動テスト駆動するように拡張したJava製のテスト補助エンジン(+フレームワーク) BDDにとっても向いてる 対応言語はJava、C#、C/C++ etc... Webサーバの機能を持ちWiki としても利用可能 Wiki の表形式記法をベースにテストケースを作成可 プラグインによる拡張で blog 機能も持たせられるらしい Fitnesseってなんぞ ※Fiｔ -> HTML のテーブル形式でテストケースを作成可能な補助エンジン

10. Fitnesseの構成 テスト実行者 Wikiの表形式でテストケースを記載する Wikiの表形式でテスト結果を表示する Fitnesse Wiki形式で記載されたテストケースを独自のデータに変換して実際のテストフレームワークに渡す 受け取ったテストケースを元にテストを実行し、その結果を返す 連携用フレームワーク

11. FitnesseはあくまでWikiの表形式によるテストケース を独自の形式に変換するツールなので、実際にテスト を実行するコードに対するフレームワークが必要 言語毎に連携させるフレームワークは異なる C/C++では「cslim」 Javaでは「FitSharp」 フレームワークは自作も可能 -> 例えば、GoogleTestをベースに作成するとか 連携用フレームワークについて

12. 仕様作成者 or テスト実行者 Wiki の表形式ベースでテストケース (テストパラメータ)を作成する プログラマー Cslim等の連携用フレームワークを用いてテストケースの雛形を作成する 結局、何をすればいいの？ 役割分担が明確！

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

14. 2.Fitnesseデモ

15. 環境：Visual Studio2010(Windows) 簡易的な仕様書を作成し、それをそのままテストケースとして稼動させる例を実装する ……予定でしたが、時間が無かったのでデフォルトに用意してあるプロジェクトを見ていく事に 実際に見てみよう

16. Wikiの表形式で作成したテスト(ケース)の自動実行 過去のテスト結果を自動で記録 テストケースのリファクタリング テスト結果やWikiページの検索 Fitnesseで出来る事まとめ

17. 連携用フレームワークを用いた専用のテストプログラム の作成が必須なので、習熟しているテストフレームワー クからの乗り換え(学習)コストが掛かる 欠点1:システム構築者の負担が重い 誰かが犠牲になって既存のフレームワークと互換の取れるフレームワークラッパを作るとプロジェクト全体が幸せになれる(ﾎﾞｿｯ cppunitやGoogleTestを利用している場合ならそこまで手間無しにラッピングできるかも(検証中)

18. 仕様がテストケースに成り得るのがFitnesseの持ち味なのに、その仕様が既に存在していると…… 更に、使用しているテストプログラムの書き換えが発生するとなると採用に二の足を踏まれ易い テスト履歴の視認性アップや管理性の向上の恩恵は受けられる 導入する事によりテストケースの見直しを行える効果はあるかもしれない 欠点2: 既存のプロジェクトへの効果が薄い

19. UI が英語 当然ヘルプも英語 国内での採用事例もほとんどないので、参考資料もほぼ全部英語 欠点3: 英語ｪ……

20. 3. 展望

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

22. 仕様書をFitnesseにそのまま食わせる事が可能な Wikiの表形式で作成する事で、 テスト実行者(実装者)が仕様を勘違いしていてテストになっていなかった 仕様変更の度にテストプログラムを書き換える必要があり、そこでエンバグを引き起こしてしまった という残念だが「良くある」事態を防ぐ事ができる。 仕様とテストケース(パラメータ)の結合が可能 個人的に Fitnesse導入の最大のメリットはこれ!

23. 便利なんだけどデータをテスト用に変換するのがめんどくさい各種テーブル等も気軽に利用可能になる -> 例:ディシジョンテーブル テスト作成工数の減少

24. Webサーバ形式なので、チームの共有サーバに設置すれば気軽に全ての人員がテスト結果を参照可能 テスト結果だけでなく、テストケースも気楽に参照可能 テスト結果の可視化、共有化が容易

25. プログラム作成者はテストの雛形までを作成 テスト実行者がテストケース(パラメータ)を作成 テストはデイリーで自動実行 という流れを構築できる。 分業の範囲も明確になる 若干プログラム作成者のコストが高めになるかも テストの流れが明快になる

26. 自動化の推進 JenkinsやSikuliといったツールと組み合わせる事に よりシステムテストの自動化まで持っていきたい 連携用フレームワーク(clism)の改造 GoogleTestばりにテスト用マクロを充実させたりして みると採用への足掛かりになるかも？ Fitnesse展望 Jenkinsについては粉川先生のCEDECの講演を参考に！ CEDiLで無料で見れます http://cedil.cesa.or.jp/

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

28. BDDって便利そうだけど…… 詳細な仕様が決まってないと 実装できないじゃん！ ゲーム開発でそれはありえない！ Pre FAQ

29. 仕様先行が本来あるべき姿 ゲーム業界にはよくある事、と仕様検討無しで実装を 開始し、後で修正……という悪習から脱却する機会 にもなりうる ただし、全てのプロジェクトに採用すれば上手く回る、 という訳ではない。基幹系は向いてるけど、試行錯誤 前提のゲームシステム部には向いてないかもしれな い。よく考えて採用するのが大事。 その考え方が悲劇を生むのです バ グ

30. 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 参考文献・サイト