現在のプロジェクトの途中で、デバッグに数え切れないほどの時間を費やすという苦痛に苦しんだ後、TDDを採用することにしました。まず、既存の各モデルの単体テストのセットを作成することを計画しています。しかし、属性のみが定義されている(つまり、追加のメソッド/プロパティがない)モデルの場合、何をテストする必要があるのか、またどのようにするのかわかりません。
class Product(models.Model):
name = models.CharField(max_length=50)
description = models.TextField(default='', blank=True)
retails = models.ManyToManyField(Retail, verbose_name='Retail stores that carry the product')
manufacturer = models.ForeignKey(Manufacturer, related_name='products')
date_created = models.DateTimeField(auto_now_add=True)
date_modified = models.DateTimeField(auto_now=True)
Productを例として使用して、単体テストでカバーする必要があることは何ですか?そしてForeignKeyとManyToManyFieldはどのようにカバーする必要がありますか?
これは私が役に立ったと思った記事でした: http://toastdriven.com/blog/2011/apr/10/guide-to-testing-in-Django/ 。ここに何をテストするかについての良い要約があります:
テストに不慣れな開発者/デザイナーにとってのもう1つの一般的な後退は、「何をテストすべきか(またはすべきでないか)」という質問です。ここにはどこでもきちんと適用される厳格な規則はありませんが、決定を行う際に提供できるいくつかの一般的なガイドラインがあります。
問題のコードが組み込みのPython function/libraryである場合は、テストしないでください。日時ライブラリなどの例。
問題のコードがDjangoに組み込まれている場合は、テストしないでください。モデルのフィールドのような例や、組み込みのtemplate.Nodeが含まれているタグをレンダリングする方法のテスト。
モデルにカスタムメソッドがある場合は、通常、単体テストを使用してテストする必要があります。
カスタムビュー、フォーム、テンプレートタグ、コンテキストプロセッサ、ミドルウェア、管理コマンドなども同様です。ビジネスロジックを実装した場合は、コードのさまざまな側面をテストする必要があります。
したがって、あなたの例では、いくつかのカスタム関数を書くまで、テストするものは何もありません。
私の意見では、ForeignKey
およびManyToManyField
リンクのテストは2番目のカテゴリ(Djangoに組み込まれているコード)に該当するので、実際にはテストしているので、これらはテストしませんDjangoが適切に機能しているかどうか。外部の関係やM2Mを含む、製品のインスタンスを作成するメソッドがある場合、データが作成されたことを確認できます。 Django機能ではなく、カスタムメソッド。
TDDパラダイムを使用して、ビジネスロジックと設計要件を検証するためのテストが作成されます。
私のCS350クラスTDDは、すべてのアクセサーとミューテーターをテストすることがベストプラクティスであると規定しました。したがって、モデルの場合、最初に各評価関数を呼び出すテストを記述し、それが適切な値を返すことを確認します。
モデルのデータフィールドを変更する関数ごとに、特にそのデータフィールドの結果をテストするだけでなく、モデルインスタンスの他のすべてのフィールドもテストして、誤って変更されていないことを確認します。 。
言い換えると、モデルにフィールドa、b、cがある場合、コンストラクタを使用してインスタンスを作成し、3つすべてが適切に設定されていることを確認します。別の関数set_a()があるとします。 「a」の値が変更されただけでなく、bとcの値も変更されていないと主張するでしょう。