45

現在のプロジェクトの途中で、数え切れないほどの時間をデバッグに費やすという苦痛に苦しんだ後、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)

例として製品を使用すると、単体テストでカバーする必要があるものは何ですか? また、ForeignKeyとManyToManyFieldをどのようにカバーする必要がありますか?

4

2 に答える 2

87

A Guide to Testing in Django (アーカイブされたリンク)という記事が役に立ちました。以下は、何をテストするかの良い要約です。

テストに慣れていない開発者/デザイナーにとってよくあるもう 1 つの挫折は、「何をテストすべきか (またはすべきでないか)」という問題です。ここには、どこにでもきちんと適用できる厳格なルールはありませんが、決定を下す際に提供できる一般的なガイドラインがいくつかあります。

  • 問題のコードが組み込みの Python 関数/ライブラリである場合は、テストしないでください。datetime ライブラリのような例。

  • 問題のコードが Django に組み込まれている場合は、テストしないでください。モデルのフィールドや、組み込みの template.Node が含まれるタグをレンダリングする方法のテストなどの例。

  • モデルにカスタム メソッドがある場合は、通常は単体テストでテストする必要があります。

  • カスタム ビュー、フォーム、テンプレート タグ、コンテキスト プロセッサ、ミドルウェア、管理コマンドなどについても同様です。ビジネス ロジックを実装した場合は、コードの側面をテストする必要があります。

したがって、あなたの例では、カスタム関数を作成するまでテストするものは何もありません。
私の意見では、テストForeignKeyとManyToManyFieldリンクは 2 番目のカテゴリ (Django に組み込まれたコード) に分類されるため、Django が適切に機能しているかどうかを実際にテストしているので、これらはテストしません。外部関係や M2M を含む製品のインスタンスを作成するメソッドがある場合、データが作成されたことを確認できます。これは、Django の機能ではなく、カスタム メソッドをテストすることになります。

TDD パラダイムを使用して、テストはビジネス ロジックと設計要件を検証するために構築されます。

于 2012-03-05T23:14:01.577 に答える