(こっちを先にしたほうが説明が楽だったな。)前述したようにモデルの単純なCRUDはテストする必要はない。モデルに実装したロジックのテストケースの話である。
技術的には、DBTestを継承したテストケースを書くのがとてもシンプルで、よい。前述のような「コミットしちゃう」という問題も起きないので、テストケースの枠組みは、
- (必要なら)対象となるデータを作成する
- 対象メソッドを実行
- 結果を確認する
- (DBTestが自動で、すべてロールバックする。作成したデータも消える。)
というだけである。実際、tests/test_model.pyにそのサンプルが入っている。
database.set_db_uri("sqlite:///:memory:") class TestUser(testutil.DBTest): def get_model(self): return User def test_creation(self): "Object creation should set the name" obj = User(user_name = "creosote", email_address = "spam@python.not", display_name = "Mr Creosote", password = "Wafer-thin Mint") assert obj.display_name == "Mr Creosote"
モデルに実装するのは、とりあえずこんな機能だ。
- 複雑な検索、データ取得
- バッチ的な更新、削除(classmethodにする?)
- 制約の実装(DDLやSQLObjectの制約で書けない、関連の制約など)
このくらいであれば、テストケースを書くのに特に問題はない。