プログラマでありたいスマートフォン用の表示で見るプログラマでありたいおっさんになっても、プログラマでありつづけたい2013-07-18テストのデータ生成は、FixtureよりFactoryモデルブログからコードの匂いがしなくなってきたので、たまには開発論の話をしてみます。最近では、当たり前のようにテストのコードが書かれるようになってきて、時代が変わってきたなぁと嬉しくなります。ユニットテストを見ていると気になる事があります。それは、データベース関連のテストをする際に、事前にテストデータを入れ込んだDBでテストしているパターンです。いわゆるFixture(フィクスチャ)と呼ばれる手法です。Fixtureの便利な点は、テストデータの準備が非常に楽という点にあります。テスト用のDBにsqliteを使っているのであれば、事前にデータを入れておいたsqliteを用意しているだけで済みます。mysql等を使う場合でも、データを用意しておいてインポートするだけで良いでしょう。非常にお手軽に思えます。欠点は何でしょう?テストコードがデータに依存し過ぎて、やがてDBのデータを変更出来なくなるという点です。いうことでしょうか?例えば、とあるテーブルに100件くらいのデータを入れていて、そのデータを元に10件くらいのテストメソッドがあったとします。新規メソッドを追加して、更にテストデータのパターンを追加する必要が出たとしましょう。何が必要でしょうか?追加したテストデータが、既存のテストに影響を与えないように注意する必要が出てきます。データが100件あるという前提での境界値テストをしていないか等ですね。100件×10件くらいだったら何とかなりますが、それが1,000件のテストコードだったら、どうでしょう?依存性を考えると、メンテナンスする気がしませんね。N*Nのパターンでテストが必要な、関連モデルのテストもデータ作るのが面倒臭いですね。すれば良いのでしょうか?その解の1つに、Factory(ファクトリー)モデルがあります。これは、テストごともしくはテスト群ごとにコードからデータを生成するパターンです。メリットとしては、前述のFixtureの欠点であったデータのメンテナンス性を大幅に向上させ、かつデータの依存性を小さく出来ます。デメリットとしては、データ生成の為にコードを書くので記述量は増えます。記述量の問題は、補助ライブラリを使うことにより負担にならない程度に減らせます。girlが有名ですね。ちなみにFixtureですが、まったくダメな子という訳では決してありません。UI層のテストを書く場合であれば、Fixtureを使った方が便利な場合も多いです。テストデータの生成方法1つをとっても拘りやノウハウがあるので、色々考えてみてください。はてなブログをはじめよう!dkfjさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。