Fixture + SQLAlchemy

Using LoadableFixtureを読む

A DataSet class is loaded via some storage medium, say, an object that implements a Data Mapper or Active Record pattern. A Fixture is an environment that knows how to load data using the right objects. Behind the scenes the rows and columns of the DataSet are simply passed to the storage medium so that it can save the data.

DataSetクラスはなんらかの格納媒体(以下ORMapper)例えばDataMapperやActiveRecordパターンで実装されたオブジェクトによってロードされる。Fixtureは正しいオブジェクトを使って、どのようにデータをロードするかを知っている環境だ。内部的にはDataSetの行と列は単純にORMapperに渡されて、ORMapperがデータを保存する。

The Fixture class is designed to support many different types of databases and other storage media by hooking into 3rd party libraries that know how to work with that media. There is also a section later about creating your own Fixture.

Fixtureクラスは多くの異なるタイプのデータベースやストレージメディアに対し、どのように接続するかを知っているサードパーティーのライブラリにフックすることで、それらをサポートするようデザインされている。後のほうに独自のFixtureを作るセクションがある。

Fixture is designed for applications that already have a way to store data; the LoadableFixture just hooks in to that interface.

Fixture はデータの格納方法を既にそなえたアプリケーションのためにデザインされている。LoadableFixture はただそのインターフェースにフックしているに過ぎない。
—————-
以下An Example of Loading Data Using SQLAlchemy を参考にデータセットとテストコードを書いた。

Read the rest of this entry »

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のセッティングを間違えると、これがメールアドレスを削除するとユーザが削除されたりして、とても危険(実際にあった)なのでこういう基本的なところは日々のテストで確認したい。