DBの制約としての再利用の検証

私は再生を使用しています！無効なモデルインスタンスを保存できるというテストを書いている間に発見されました。いくつかのインスタンス変数には無効な値があります。私はそれが検証と永続性を分離した状態に保つために期待される動作だと思います。しかし、データベース制約として検証アノテーションを再利用する方法はありますか？DBの制約としての再利用の検証

出典

2011-07-13 Manuel Leuenberger

私はPlayについて何も知らない。 JSR 303検証アノテーションを使用していますか？ Play documentationによれば、永続化のためにHibernateを使用できます。 Hibernate 3.5では、生成するスキーマ内でJSR 303アノテーションを使用して表現されたHibernate will include constraintsが表示されます。

出典

2011-07-13 14:15:42

JPAではなく、Hibernateに固有のことだと思いますが、間違っている可能性があります。また、Playではデフォルトで無効になっている可能性があります。しかし、ありがとう！ –

はい、私が示したように、それはHibernate 3.5以降に特有です。私がリンクしているPlayドキュメントは、PlayがHibernateを使用できる、または使用していることを示しているため、これは実行可能でなければならないようです。 –

これはPlayがJPA（実装としてのHibernate）を使用するため無効になる可能性があるので、今晩テストする必要があります。私は、私が持っているプロジェクトの中には、それらを適用していないという事実を知っています。おそらくそれです。互換性のためにデフォルトで無効になっています（または有効になっていません）。 –

いいえ、検証はデータベースの制約にリンクされていません。新しいevolutionsフレームワークのPlay 1.2.1を使用するなど、SQLを使用してデータベースに手動で制約を追加する必要があります。

ユニットテストでは、正しいデータを確認する必要があります。いずれにしても、モデル内のロジックをテストするだけで、クラス間の依存関係はなく、誤ったデータで保存されたインスタンスについては心配する必要はありません。

統合テストとセレンテストでは、コントローラコールで@Valid経由でPlayで提供される検証システムを使用できるはずです。ここでは、悪いデータを持つオブジェクトが永続化されていないことを確認し、いくつか追加しようとします。

出典

2011-07-13 14:05:09

evolutionsを使用していただきありがとうございます。私にとっては、モデルインスタンスの検証は、有効なものと不可能なものを決定するロジックがモデルの責任にあるため、単体テストに属します。私が単体テストで無効なモデルを保存しようとしたのは、純粋な奇妙なことから起こったのですが、それが私の精神モデルを破りました。さて、もう一度修正されました;） –

DBの制約としての再利用の検証

答えて

関連する問題