DBまわりのテストを簡単にするfixture

fixutre というpythonモジュールは、テストに関するDBの面倒をみてくれる様子。
個人的にはteardown, setupをリッチに一元管理できるという感覚で捉えています。
http://farmdev.com/projects/fixture

• テストDBにデータをロードし、アサーションするときに簡単に参照したい
• 外部キーとリレーションのあるデータを自動的にロードし、integritty errorなしに簡単に削除したい
• IDではなく意味のある名前で接続された行を参照したい
• auto-incrementを気にしたくない
• バグを検証するためにDBの実際のデータにSQLを発行し、環境を再構築したい
• ファイルについてファイルシステムに依存せずテストしたい

意訳するとこんなとき便利らしい。

Loading and referencing test data

There are a couple ways to test a database-backed application. You can create mock objects and concentrate entirely on unit testing individual components without testing the database layer itself, or you can simply load up sample data before you run a test. Thanks to sqlite in-memory connections, the latter may be more efficient than you think.

But it’s easy enough to insert data line by line in code, right? Or simply load a SQL file? Yes, but this has two major downsides: you often have to worry about and manage complex chains of foreign keys manually; and when referencing data values later on, you either have to copy / paste the values or pass around lots of variables.

The fixture module simplifies this by breaking the process down to two independent components:

DataSet
Defines sets of sample data
Fixture
Knows how to load data

DBアプリをテストする方法はいくつかある。DBのレイヤーそのもののテストはせずに、モックオブジェクトをつくって完全に個々のコンポーネントのユニットテストに集中するとか、または単純にテストを走らせる前にサンプルデータをロードする手もある。sqliteのin-memory 接続のおかげで、後者は思ったより効果的。

でも一行一行コードにデータを入れていくのってホントに簡単か？それかシンプルにSQLファイルをロードしてまう？ いいけどでもこれは２つの大きな欠点がある。しばしば外部キーの連鎖に配慮したり、手で管理したりしなければならない。そしてその後にデータの値を参照するときに、値をコピペするか、たくさんの変数をたらい回しにしなければならない。

fixture moduleはこれを、二つの独立したコンポーネントにそのプロセスを分けることで単純化している。

DataSet
サンプルデータのセットを定義
Fixture
データのロードの仕方を知ってる

(意訳終わり)

個人的に使いたい状況は、例えばUserとEmailの2つのテーブルがあるとする。Userのあるレコード(仮にbob)を削除すると、bobの持つメールアドレスbob@example.com, bob@bob.netもEmailから消したい。ORMapperのセッティングを間違えると、これがメールアドレスを削除するとユーザが削除されたりして、とても危険(実際にあった)なのでこういう基本的なところは日々のテストで確認したい。