STAR Auto Testing Frameworkでドキュメント駆動開発 ぎじゅっやさん

ツイート 以前の記事でSTAR Auto Testing Frameworkを紹介した。
（作者本人も驚いていたようだ。）
今回は実践してみたのでその辺りを書いてみようと思う。

テスト駆動開発を実践する上で、
私はテストケースをというコードを書くことに異議を唱えた。
（もちろん理解者はゼロ）
理由は以前も書いたが、
テスト仕様書とテストケースという内容が全く同じで言語が違うだけもの２回も用意する意味がないからだ。
仕様書を書けばテストケースが出来上がるのが理想の形だろう。
そうすれば仕様書とテスト内容が異なるようなことも起きない。

似たような例にデータベースがある。
MySQLにはMySQL Workbenchというデータベース設計ツールがある。
（旧DB Designer4と言えばわかるだろうか。）
これでDB設計し、ER図を書くと、SQL分が発行されデータベースが出来上がる。
こうすることで設計書と実際の齟齬を無くしている。


逆にドキュメントを書かないとテストも出来ないし、
ＥＲ図を描かないとＤＢができないので、
ドキュメント作成の意識も高まるといえる。


STAR Auto Testing Frameworkは単体テストとＳＴに対応している。
前者はPHPUnit, JUnitを使用、後者はSeleniumを使うことを前提としている。
これら一つ一つだけでも一冊の本があるぐらいなのでここでは詳細な説明は省く。
そして私はJavaに明るくは無いのでJUnitのことは今回は取り上げないが内容に差はないと思う。
あと文章が長くなったので今回は単体テストだけ行う。

PHPUnitはSimpleTestと並んで割と一般的に使われているテストフレームワーク。
テストケースを作成しphpunitとコマンドを打てばがんがんテストをしてくれる。

Seleniumはブラウザを使って自動テストをしてくれるテストフレームワーク。
いくつか種類があるがSTAR Auto Testing FrameworkではFirefoxプラグインのSeleniumIDEを使うことを想定しているようだ。


では実際どのような流れになるのか。
全体的なフローは以下の通り。

1. 仕様書を作成する
2. 空のプログラムを作成
3. 全部エラーになるようにテスト仕様書の作成
4. テストケースの生成
5. テスト実行しエラーになるのを確認
6. 実装作業
7. テスト実行しエラーがなくなるのを確認

重要なのは最初のテストを全部エラーになるようにし、
実装後すべてのエラーが出なくなることを確認すること。
こうすることで一つのメソッドに対する入出力を保障することが出来る。
テストのパターンは自身が想定しうる問題すべてを網羅しておくこと。

[More:]

１、仕様書の作成
趣味でやるのならともかく仕事でやるのであれば仕様書を作るのは当然。
別にWordやExcelで無くてもWikiやEvernoteとかで構わない。


２、空のプログラム作成
べた書きならPHPのファイル、
フレームワークならアクションやコントローラクラスをジェネレーターなどで枠だけ作っておく。
そして上記の仕様書から使うであろう主なメソッド、関数を書く。
例えば半角英数字をチェックするプログラムを書くとする。
クラスにすると以下のようになるだろうか。

class AlphaNum {
 public static function isAlphanum($value) {
 }
}

参考: http://lab.tricorn.co.jp/satoo/2185

中身を書かないのがポイント。

３、テスト仕様書を書く
http://sourceforge.jp/projects/starautotest/
より「STAR UnitTest /PHP」をダウンロード。
STARUnitTestPHP.xlsを開いてテスト定義タブを開く

テストクラス名

AlphaNumTest

require_once 文

require_once 'AlphaNum.php';

No1のメソッド名

testIsAlphanum

テストコード"コード"

$this->assertTrue(AlphaNum::isAlphanum(#1));

テストコード"#1"

"abc123"

テストコード"#2"

半角英数字

４、テストケースの生成
ツールタブの「テストケースの生成」をクリックする

５、テスト実行しエラーになるのを確認
phpunitコマンドを実行しテストがエラーになるのを確認する。



５．１、テストを追加
テストコードに想定できる入力パラメータを使ったテスト項目を追加する。
サンプルとして以下のように増やしてある。


５．２、テスト実行しエラーになるのを確認
テストを生成しもう一度実行してみよう。（結果は同じになる）

６、実装作業
ここでようやく実装作業開始。

７、テスト実行しエラーがなくなるのを確認
実装完了後テストを実行しすべてのエラーがなくなることを確認する。



さて、長くなって申し訳ないがこれで流れはわかってもらえただろうか。
こうすることで仕様書とテスト、実装をすべて一致させつつ品質を保証することが出来る。
ビギナーにはチンプンカンプンだと思うが、
慣れてくると確認を怠って事故ることが多発する。
一つの仕組みを修正したら別の箇所で事故が起こったり、
リファクタリングしたらバグがでたりするが、
こうやって入出力を保障しておけば中身をどのように替えても安全だ。


参考:
STAR Auto Testing Framework
http://lab.tricorn.co.jp/satoo/2185