テスト環境を構築

今やってる仕事で使っているフレームワークは非公開のもので、
テスト環境が用意されてなかったので、さくっと作ってテストしてます。

Web系のテスト環境としては、やっぱりRailsが参考になる。
Railsでは、モデルのテストとコントローラのテストの大きく２つに分かれるのだが、
今回つくったのは、モデルのテスト的にコントローラもテストできる仕組み。
私はSeleniumのようにブラウザでの自動テストやRailsのコントローラテストのように返ってきたHTMLを解析(といってもRailsがほとんど自動でやってくれるのだが。。。)するようなテストはあんまり好きじゃないし、画面はデザインとかでコロコロ変わるので、きっちりしたテストを書く意義をあんまり感じない。(投資対効果的な意味で)

だったら、(モデルとコントローラに書かれているであろう)ロジックをしっかり単体テストとして書いておいて、
画面はさくっと手作業で確認したほうがよほど効率が良い気がする。
どのみち、IEで崩れないかとか見ないといけないのだし、画像がリンク切れしてないかとか、画像がちゃんと縮小されてるかとか。。。

で、今回ちょっと悩んだのが
フィクスチャの持ち方。
Seasar2系のテストだと、テスト毎にエクセルファイルを用意し、１タブ１テーブル的にデータを突っ込んでおくのが定石。
イリーガルなパターンもフィクスチャさえ用意すれば簡単に対応できるのだが、
テーブルに変更があった場合、すべてのフィクスチャに影響が出るのでそこが大変なところか。

変わってRailsは基本の情報をフィクスチャとして用意しておき、
イリーガルなパターンなどは、テスト時にモデル経由でinsertやらupdateをするのが定石のよう。
フィクスチャは１プロジェクトで１テーブル１ファイルとなるので、テーブルに変更があってもフィクスチャファイルへの影響は最小限ですむが、
イリーガルな状態を作るのが大変なときは、テストが長くなってしまう。

今回は、Seasar2のように、フィクスチャをテストクラス側で指定してそれを使用するようにした。
理由は、こっちの方がイリーガルなパターンへの対応が簡単だからと、テスト間の依存は最小限にしたかったため。
こっちのテストのために、データ追加したら他のテストが失敗したなんてことは御免なので。

単体テスト環境が無いフレームワークは最近そう無いんだけども、
無いフレームワーク(オレオレフレームワークとか)では、テストかけねーよと嘆く前に作ってみるのが良い。
最小限の機能なら数時間程度で書けるし、テストがあると安心感が違う。
初めて使うフレームワークならこれはめちゃんこ勉強になる、ヘタにサンプル的なものを作るよりよっぽどフレームワークに精通できる。(これも学習テストみたいね。by CleanCode)

話は変わって、今月１４日に待望の本、

レガシーコード改善ガイドが発売される。

本の発売日は結構適当なのもしれんと、淡い期待を抱きつつ毎日のように本屋に足を運んでますｗ
これは絶対買い。