2017-01-10 8 views
0

最近私はDjangoプロジェクトに取り掛かりました。まず、book on TDD with Pythonと公式文書(tests)を読んでいます。さらにいくつかのブログもあります。Django - モックでユニットテストを書く

私が気付くことは、データベースモデルにアクセスするテストを書くことです。 Itemオブジェクトの数は1だからテストが実際に追加され、データベースからデータを取得するかどうかをテストがアサートhere

def test_home_page_can_save_a_POST_request(self): 
    request = HttpRequest() 
    request.method = 'POST' 
    request.POST['item_text'] = 'A new list item' 

    response = home_page(request) 

    self.assertEqual(Item.objects.count(), 1) 
    new_item = Item.objects.first() 
    self.assertEqual(new_item.text, 'A new list item') 

から次のスニペットを考えます。テストを遅くするのではないでしょうか?

テストが並列化されている場合、Itemオブジェクトを追加する別のテストがあると、このテストケースが失敗する可能性があります。

パッチ方法/オブジェクトはどうですか?上記のスニペットは、私はジャンゴに新しいです。この

@patch('my_app.views.Item') 
def test_home_page_can_save_a_POST_request(self, mock_item): 
    request = HttpRequest() 
    request.method = POST 
    request.POST['item_text'] = 'A new list item' 

    response = home_page(request) 

    self.assertTrue(mock_item.objects.create.called) 

のようにリファクタリングすることができ、私は実務に精通していないです。私が訪れたチュートリアルでは、データベースと話すテストが書かれていました。私はこれがDjangoプロジェクトのテストのための規約であるかどうかを知りたいと思います。 Djangoエコシステムで2番目のスニペット(パッチとモックを使用しています)は完全にうまくいきますか?

編集:Formsと同様に - またはFalseを返すform.is_validメソッドを模倣します。ただし、フォームの単位テストが別途必要です。

P.S. Pythonを使ったTDDは素晴らしいオンボードです。私は間違いなくDjangoを学ぶ人にそれをお勧めします。

+0

テストは独自のトランザクションで実行されるので、利用可能/予想されるデータまでは互いに独立してテストされます。 (本へのポインタありがとう - すごくいいですね) –

答えて

1

モデルをテストする場合、データベースをバイパスすることはほとんどありません。メモリ内のSQLiteデータベースを使用していてもテストをいくらか遅くすることができます。これは、SQLiteが他の問題につながる可能性があります。 PostgreSQLのようなものの透明な代替品ではありません。

あなたのビューで呼び出すモデルやその他の関数/オブジェクト/メソッドが独自のunittestを持っていて、あなたの見解を確認したいと仮定していると仮定すると、モックは実行可能な戦略です - (主にユニットテストを統合テストに変えます)。

+0

私は同じことが 'Forms'にも当てはまると思います。 'form.is_valid'を模倣して' True'または 'False'を返し、私のSUTをテストできます。もちろん、フォームの単体テストを書いた後。 – shar

関連する問題