1

このテストをより適切に記述したい:

def test_profile_created(self):
        self.client.post(reverse('registration_register'), data={
            'username':'ygam',
            'email':'ygam@example.com',
            'password1':'ygam',
            'password2':'ygam'
        })
        """
        Test if a profile is created on save
        """
        user = User.objects.get(username='ygam')
        self.assertTrue(UserProfile.objects.filter(user=user).exists())

そして、実際にはユーザーを「作成」しないdjango-registrationテストでこのコードに出くわしました:

def test_registration_signal(self):
        def receiver(sender, **kwargs):
            self.failUnless('user' in kwargs)
            self.assertEqual(kwargs['user'].username, 'bob')
            self.failUnless('request' in kwargs)
            self.failUnless(isinstance(kwargs['request'], WSGIRequest))
            received_signals.append(kwargs.get('signal'))

        received_signals = []
        signals.user_registered.connect(receiver, sender=self.backend.__class__)

        self.backend.register(_mock_request(),
                              username='bob',
                              email='bob@example.com',
                              password1='secret')

        self.assertEqual(len(received_signals), 1)
        self.assertEqual(received_signals, [signals.user_registered])

ただし、彼はこの「_mock_request」にカスタム関数を使用しました。

class _MockRequestClient(Client):
    def request(self, **request):
        environ = {
            'HTTP_COOKIE': self.cookies,
            'PATH_INFO': '/',
            'QUERY_STRING': '',
            'REMOTE_ADDR': '127.0.0.1',
            'REQUEST_METHOD': 'GET',
            'SCRIPT_NAME': '',
            'SERVER_NAME': 'testserver',
            'SERVER_PORT': '80',
            'SERVER_PROTOCOL': 'HTTP/1.1',
            'wsgi.version': (1,0),
            'wsgi.url_scheme': 'http',
            'wsgi.errors': self.errors,
            'wsgi.multiprocess':True,
            'wsgi.multithread': False,
            'wsgi.run_once': False,
            'wsgi.input': None,
            }
        environ.update(self.defaults)
        environ.update(request)
        request = WSGIRequest(environ)

        # We have to manually add a session since we'll be bypassing
        # the middleware chain.
        session_middleware = SessionMiddleware()
        session_middleware.process_request(request)
        return request


def _mock_request():
    return _MockRequestClient().request()

ただし、私のニーズには長すぎる機能かもしれません。どうにかしてアカウント作成を「偽装」できるようにしたいです。私はモックとスタブの経験があまりないので、どんな助けでも構いません。ありがとう！

4

2 に答える 2

2

これら 2 つのアプローチは、異なるものをテストしています。

  1. テスト ケースはモデル レイヤーをテストします。「ユーザーを作成して保存すると、プロファイル レコードは自動的に作成されますか?」という質問が表示されます。

    ユーザー オブジェクトがどのように作成されたか (管理ビュー、ユーザー サインアップ ビュー、管理コマンドなど) に依存しません。このテストに合格する限り、ORM を使用してユーザーを作成する方法はどれでもかまいません。プロファイルを追加します。

    また、プロファイルの作成方法も気にしません。保存前のシグナル、保存後のシグナル、オーバーライドされた save() メソッド内のコード、またはマジックによる可能性があります。レコードが作成されている限り、テストはパスします。

  2. django-registration で見つけたコードは、ビュー レイヤーをテストしています。特定のビュー関数を呼び出し、register3 つの URL パラメータを渡し、「user_registeredこのビューの結果としてシグナルが発生したか?」という質問をしています。

    このテスト ケースでは、ユーザーを作成する他の方法は調べていません。登録ビューだけです。ユーザーを作成する他の方法には関係ありません。

    また、プロファイルが作成されたかどうかも調べません。知りたいのは、その信号が特定のアプリケーションで実際に何をするかに関係なく、信号が起動されたことだけです。

違いは何ですか？

あなたのコードは統合テストの良い例です。-- および回帰テストの 、ユーザー プロファイルの作成を壊すようなことをしたかどうかを将来知らせます。

django-registration コードは実際の単体テストです。制御された環境で呼び出して簡単な質問をするために、ビューコードだけを非常に慎重に分離します。

どちらが良いですか？

あなたの場合、おそらく単体テストを書く必要はありません。（それについては多くの議論があるかもしれませんが、実際には一部では宗教の問題です）あなたは、まとめたコードが期待どおりに機能していることを確認する方法と、テストそれを行うための最良の方法です。

実際にユーザーを作成することについて心配する必要はありません。テストの実行中は、トランザクションですべてを実行しており、そのトランザクションはテスト メソッドが完了するとすぐにロールバックされます。ディスクにヒットすらしないかもしれません。そして、@Platinum Azure が述べたように、とにかくすべてテスト データベース上にあります。

于 2012-09-28T05:33:27.583 に答える
0

なぜユーザー作成をモックアウトしたいのですか？Djangoのテストエンジンを実行している場合は、テストデータベースに対してテストしています。ビューを呼び出すか、リクエストクライアントファクトリを使用して、テストランナーがテストデータベースを削除できるようにします。

于 2012-09-28T03:45:10.593 に答える