投稿日:2009年5月31日 -投稿者 ohyanagi
PHP で TDD その3
こんにちは中の人です。
先週自身が関わっていた案件のサイトがローンチしました。
私が関わったのはサイトのメインの箇所から少し離れた箇所の担当でした。
# メインは別の開発チームが開発しました。
今回の開発では TDD で開発し、開発スタイルをいつもと変えるという事を自分自身のゴールにしました。
前回は TDD にして何が嬉しいかは持ち越しで締めたので、今回は何が嬉しかったのかを書いて行きたいと思います。
今回は一切コードが出てこないので気軽に読んで頂ければと思います。
今回の開発では短期間の開発、テスト環境は色んな人が触っているという前提条件でした。
個人で確認できるような環境があれば他の人が触る心配はないですが、今回は共通のテスト環境のみでした。
勿論構成管理は行っているのですが、短期間だったためマージ作業のコストも馬鹿にならなかったため気軽にテスト環境を更新できませんでした。
行った方法としてメインの機能からはクラス(ライブラリ)を呼びデータを渡し、結果をメインに返すというような方向性で行く事にしました。
ライブラリ部分の開発に比重を置き、ライブラリの開発には TDD で行いました。
■TDD にして良かった点
・テストコードがあるため気軽にリファクタリングができた
・毎日開発する前にテストコードを実行して前日まで作った部分に異常がない事を確認できた
・ブラウザを経由して実施するテストでも不具合が出た部分の特定がある程度予想できた
■TDD を行った後に見えた課題
・毎回テストコードを手動するのは結構めんどくさい
・期間限定のテストコードが出来てしまう
→ サーバ日時に依存したテストや、DBのデータに依存したテストコードが出来てしまうので、テストコードが将来的に動かなくなってしまう
今回は PHPUnit + Piece Project の Stagehand_Testrunner を使用しました。
課題の 1 つめに関しては CI サーバを導入するか、ファイルの更新を検知したら Stagehand_Testrunner が自動的に動作するような物を探せば良いと思います(なければ作ればいいでしょう)。
2 つ目の課題は解決方法を模索している途中ですので、良い方法があれば教えて頂ければと思います。
現状できるだけライブラリの外からデータを渡す方法で実装し、テストの際にはテストデータを渡してテストする方法を取っています。
■まとめ
TDD を行うというのはテストコードを書かなければ行けないのでコストが高いと思われがちですが、実際にはそんな事はありませんでした。
むしろ開発が終盤になってコードに手を入れる場合に回帰テストを行えるので影響度合いがすぐに分かりました。
そのため安心してリファクタリングを行えるが良かったです。
全部の箇所にテストコードを書くのは難しいので、まずはライブラリ部分からとか導入するのが良いかと思います。