今ひとつTDDとかBDDに対して懐疑的とゆーか今ひとつよく分からない。
やっぱり「テスト」という言葉があまりにも対象とする範囲が広すぎる為、ボタンを掛け違えてしまうような気がする。
YakiBikiでも一部UnitTestを採り入れているけど、UnitTest化しているところは内部的なデータのI/O部分だけで、HTMLやセッションなどブラウザやHTTPと絡む部分はUnitTest化していない。テスト用のプログラムを書くのが面倒くさいというのがある。プログラムの内部で使われるAPIとかインターフェイスなら分かりやすいのだけれど。Seleniumとかの話を聞いてしまうと、UI部分までUnitTestするの？
しかもそんなころころ変わる部分を「機械に」やらせたとしても・・・なんかなぁ。人間がやったほうが早くない？という感情がある。
とりあえず今日の感想としては、やっぱ言うほどTDDって浸透してないのかと。テスト厨的には「あとからテストするのがめんどくさい」っていわれると「いやテストじゃなくてふるまいを決めてるんだ」とか「TDDのテストは設計をしていることだ」とかといろいろ説明をつけているわけですが、あまり実感をしてもらってないみたい。
2008-09-15 - kunitの日記
"test"と言おうが"behaviour"と呼ぼうが、結局ソフトウェアが他のソフトウェアの動作を観測し、判別しなくちゃいけないわけで、観測や判別のための記述量を如何に減らせるかや、ソフトウェアに観測可能な動作の種類や限界の見定めとかもあるし。
例えば外部I/Oとのやりとりが発生しない、純粋なロジック処理であれば、それを囲い込んで動作を観測する事も容易だと思う。
DBとだけやりとりする業務ロジックであれば、まぁテストデータを出し入れするユーティリティコードを用意してそれと一緒に囲い込めば、特定のレコード状態なども安全に再現できるので有意義だと思う。
それでもMySQLとかPostgreSQLであれば「テスト用データベース」の作成も比較的楽に出来るが、テーブルスペースの調整など色々下準備を要するOracleなどであればテスト用の砂場DBの準備もまた大変。まぁ一度作ればokなモノだろうけど。
だけど例えばHTMLのある特定のエレメントが「赤色で」表示されている事であったり、ある特定のdivタグ内のインライン要素が左寄せになっている事であったり、とかは非常に難しいか、機械化しても意味が無いと思う。
機械化による自動実行は回帰テストには有用だろうけど、人の目に触れるUI部分については変更も激しいし、そもそも機械による観測が難しいと思う。JavaScriptが混ざったらどうなるのよ、とか。
もし回帰テストの目的が「ある変更箇所が他に影響していないか」の確認だとすれば、UI系はそれこそ人間が一度動かせば確認できるわけだから、苦労して機械化する意味が分からない。
逆に業務ロジックなどで、カラムやコード値の追加・削除などで既存の挙動が崩れないか、を確認するには、機械化された回帰テストシステムがあれば有用だと思う。
UI部分はTDDやBDDの対象にはならないとすれば、例えばネットワークのソケット通信によるI/Oが発生する業務ロジックであればどうだろう。SOAPやXML-RPCやRESTなどの最近のものではなくて、基幹系であったりレガシーと通信するような業務ロジックでは充分有りうる。
しかもselect(2)などを使って複数のソケットで非同期に読み書きする前提で。
あるいはファイルの読み書きで「失敗」した時のロジックを確認するには？それはTDDやBDDの対象にはならないのだろうか？OSのAPIレベルでの「失敗」発生時のロジックはTDDやBDDでカバーできるのか？そうなったときの処理はTDDやBDDが言う「設計」の範囲内なのだろうか？
とかとかとかとか。「こーゆー時どーすんの！？」とか「どこまで機械化できるのよ！？」とかが正直、全然見えてこない。
機械化による、自動化された回帰テストシステムとして、業務ロジックのみを対象としたテスト用のゆりかごというか、ボックスというか囲い込みというか専用の砂場環境というか、そういうのは意味もよく分かるのだけれど。
また運用・保守以降を納品した先の開発部隊が行う場合、果たしてそのままTDDやBDDを適切に遂行してくれるのか？
開発時にコーディングしたテストコードも、設計とテスト完了後は保守されなくなってしまい、実体と乖離してしまうのでは？とか。
そうなると開発側だけがTDDやBDDするだけじゃ駄目で、運用・保守のフェーズでも継続しないと意味無いよね、とか。
逆に「いや、あくまでも設計時や製造時の"ツール"として割り切って使えば良い」と開き直ったとしても、そういったテストコードを作成する時間はやはりお客様に請求しなければならないのだろうか？少なくとも見積もりには入れるよな？
テストコードを以て設計やテストのエビデンスとして認めてくれるお客様であればすんなり通るだろうけど、結局はExcelなりWordなりUMLなりで作成したドキュメントとしての設計書や、実行結果のログやスクリーンキャプチャをぺたぺた貼り付けたテストエビデンスが要求されるのであれば、苦労して作ったテストコードは何だったんだ一体と言いたくもなる。
・・・ディノに乗り込んでいってkunitさんと直に議論した方が早いのかな・・・。
