3.4.0環境にはpyvenvコマンドが付帯している。1.7の構成が出来上がっている。helloworld_django17pyvenvの環境としてpython3.4.0-django1.7をそのまま使ってよければこれでおしまい。information.1.6でテストの探され方が変わっているけどお前のテスト大丈夫か、と聞いている。全てのテストが期待通りに実行されるか調べること。teardown.これを確認した上で、settings.pyに以下を追加する。標準のクラスを明示しているだけ。所定のURLにアクセスした際に指定したproviderの認証ページに移動し、認証成功時にSOCIAL_AUTH_PIPELINEのモジュールを実行する。googleならメールアドレス、Twitterなら数字文字列UserとUserSocialAuthは1対多の関係になる。一つのUserに異なるproviderやuidのUserSocialAuthが複数連なる。...既存のユーザが同じemailアドレスを使っているようならそのオブジェクトを再利用するパイプラインにsocial.pipeline.social_auth.associate_by_emailを挟む。'social.pipeline.user.user_details')ただし相手にするプロバイダによっては注意が必要。associate_by_emailの段階で任意のアカウントの乗っ取りを行えてしまう。http://syncer.jp/twitter-screenname-userid-converter)uidを調べるところから行う場合は例えば以下のようにする。よってURL上のルートが変わっている場合には上のインストラクション通りでは動作しないので注意。'https://www.google.com/accounts/o8/id'このモジュール、細部で微妙なところがあるっぽい。いう形式で動作させようとすると、うまく行かない。後で自分で直す......。/opt/yourapp/dataとすると/opt/yourapp/data配下のファイルのみ対象となる。DBをモックアウトしないが、Viewのテストでは普通にデータベースは自動的にモックのものが与えられる。アクセステストをする際のヘッダを追加する例として前述したgithubのwebhookを受け取るサーバのテストを考える。https://developer.github.com/webhooks/2014-06-17時点ではX-Github-EventやX-Hub-SignatureがHTTPヘッダに含まれる。この場合、Djangoのサーバ側ではrequest.META.get('HTTP_X_GITHUB_EVENT')やrequest.META.get('HTTP_X_HUB_SIGNATURE')として値を受け取ることが出来る。1.6であれば単に引数に含めてしまえば良い。