SQLを使ったテストの前提条件はどう作ってますか？
SQL自体を単体テストしようと思った時、テストクラスで
- Tableに前提条件となるデータを登録
- テスト対象処理呼び出し、結果のassert
- Tableをテスト前の状態にする(rollback)
という形をとると思います。
その中でも、「1」の前提条件となるデータを登録する処理をテストクラスで記述する所、みなさんはどのように楽をしているでしょうか？
SkinnyならFactoryGirl？
SkinnyFrameworkを使っている方はFactotyGirlでしょうか？
確かに、RoRの文化に慣れているとこの辺りを使う人が多い気がします。
ですが、テストプログラム上で登録する方式だと面倒なこともるはずです。
テストに使っているデータを確認したい時
「何かうまくいかない」時はテストクラスを見て、前提条件にどんなデータが入っているかを確認するはずですが、テストクラス上のソースコードだけでどんなデータが入っているかを把握するのは難しくありませんか？
結合パターンを増やしたい時
2,3個のテーブルに、それぞれ10件程度データを入れてSQLの確認をしたい時もあるはずです。そのデータを作るのをテストプログラムで記述した場合、前提条件のデータを登録する箇所だけでテストクラスの大半を占めることになりませんか？ロジックを組み合わせてデータを設定している場合、そのロジックが正しいことも気にしなければなりません。
自分が作るだけならまだしも、ほかの人が作ったテストクラスをメンテしなければならない場合、あまり考えずに理解できた方が良いと考えています。本当にFactoryGirlしか選択肢がないのでしょうか？
私はDbUnitを使います
昔からありますが、DbUnitを使うことで、ExcelのファイルをDBにImportすることができます。Javaで作られているのでScalaからも簡単にアクセスできます。
Fixtureの定義の為だけに使っているので、DbUnitである必要性も少ないのですが、あんまりこの手のツールが無いので使い続けているのが現状です(まぁ、今ある機能で事足りているというのもあります)。新しいことを受け入れられない老害？かもしれませんね...w
Excelファイルのフォーマット
こんな感じです。
実際にどう使うの？
単体テストでDB接続の是非
プロジェクトや人によっては準備が面倒だとか、SlowTestなので嫌だ、という方もいらっしゃるかもしれませんが、個人的には抑えるべき所はやった方が良いんじゃないかな、と思っています。フレームワークの動作確認とかにも使えますしね。
テスト対象のロジックのパラメータパターンが多くて、テストプログラムで作るのがかったるい時なんかは、「DBからデータを取ってきて処理を行う」箇所をテストの対象として書いたりもしてます。テストが無いよりは何倍もマシでしょう...と心の中で言い訳しつつ。
ぜひ、テストデータをExcelで管理する人気を上げていきたいと思っています。