Django
デバッグ
サーチ…
備考
Pdb
Pdbは、(Pdb)プロンプトにglobals()
またはlocals()
をそれぞれ入力することによって、 globals()
スコープまたはローカルスコープの既存の変数をすべて出力することもできます。
Pythonデバッガ(Pdb)の使用
最も基本的なDjangoのデバッグツールは、Python標準ライブラリの一部であるpdbです。
初期化ビュースクリプト
簡単なviews.py
スクリプトを見てみましょう:
from django.http import HttpResponse
def index(request):
foo = 1
bar = 0
bug = foo/bar
return HttpResponse("%d goes here." % bug)
サーバーを実行するコンソールコマンド:
python manage.py runserver
インデックスページを読み込もうとすると、DjangoがZeroDivisionError
を投げることは明らかですが、コード内でバグが深いと思われる場合は、実際には厄介になる可能性があります。
ブレークポイントの設定
幸いにも、私たちはそのバグを追跡するためにブレークポイントを設定することができます :
from django.http import HttpResponse
# Pdb import
import pdb
def index(request):
foo = 1
bar = 0
# This is our new breakpoint
pdb.set_trace()
bug = foo/bar
return HttpResponse("%d goes here." % bug)
pdbを使用してサーバーを実行するコンソールコマンド:
python -m pdb manage.py runserver
今すぐロードブレイクポイントがシェルでプロンプト(Pdb)を起動すると、ブラウザが保留状態になります。
pdbシェルによるデバッグ
シェルを介してスクリプトとやりとりすることによって、そのビューをデバッグする時間です。
> ../views.py(12)index()
-> bug = foo/bar
# input 'foo/bar' expression to see division results:
(Pdb) foo/bar
*** ZeroDivisionError: division by zero
# input variables names to check their values:
(Pdb) foo
1
(Pdb) bar
0
# 'bar' is a source of the problem, so if we set it's value > 0...
(Pdb) bar = 1
(Pdb) foo/bar
1.0
# exception gone, ask pdb to continue execution by typing 'c':
(Pdb) c
[03/Aug/2016 10:50:45] "GET / HTTP/1.1" 200 111
最後の行では、私たちの見解はOK
応答を返し、必要に応じて実行していることがわかります。
pdbループを止めるには、シェルにq
を入力するだけです。
Djangoデバッグツールバーの使用
まず、 django-debug-toolbarをインストールする必要があります:
pip install django-debug-toolbar
settings.py :
次に、それをプロジェクトにインストールされているアプリケーションに組み込みますが、注意してください。デバッグツールバーのような開発専用のアプリケーションやミドルウェアには、別のsettings.py
ファイルを使用することをおsettings.py
ます。
# If environment is dev...
DEBUG = True
INSTALLED_APPS += [
'debug_toolbar',
]
MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware']
デバッグツールバーも静的なファイルに依存しているので、適切なアプリも含めてください。
INSTALLED_APPS = [
# ...
'django.contrib.staticfiles',
# ...
]
STATIC_URL = '/static/'
# If environment is dev...
DEBUG = True
INSTALLED_APPS += [
'debug_toolbar',
]
場合によっては、 settings.py
INTERNAL_IPS
もsettings.py
必要がありsettings.py
:
INTERNAL_IPS = ('127.0.0.1', )
urls.py :
urls.py
では、公式ドキュメントが示唆するように、次のスニペットでデバッグツールバーのルーティングを有効にする必要があります。
if settings.DEBUG and 'debug_toolbar' in settings.INSTALLED_APPS:
import debug_toolbar
urlpatterns += [
url(r'^__debug__/', include(debug_toolbar.urls)),
]
インストール後にツールバーの静的情報を収集する:
python manage.py collectstatic
つまり、デバッグツールバーがプロジェクトのページに表示され、実行時間、SQL、静的ファイル、信号などのさまざまな有益な情報が提供されます。
HTML:
また、 django-debug-toolbar
は、適切にレンダリングするために、 Content-typeのtext/html
、 <html>
、および<body>
タグを必要とします。
場合は、すべての権利を構成したが、デバッグツールバーはまだレンダリングされていない場合: この "核"の解決策を使用してそれを把握しようとします。
"assert False"を使うと、
開発中に、コードに次の行を挿入します。
assert False, value
この行が実行されたときにdjangoがエラーメッセージとして提供された値でAssertionError
を発生させます。
これがビューまたはビューから呼び出されたコードで発生し、 DEBUG=True
が設定されている場合は、多くのデバッグ情報を含む完全で詳細なスタックトレースがブラウザに表示されます。
あなたが完了したときにラインを削除することを忘れないでください!
デバッガを使う代わりに、より多くのドキュメント、テスト、ロギング、アサーションを書くことを検討する
デバッグには時間と手間がかかります。
デバッガでバグを追跡するのではなく、コードを改善するために時間を費やすことを検討してください。
- テストを作成して実行します。 PythonとDjangoには、組み込みのテストフレームワークが用意されています。これは、デバッガを使って手動で行うよりもはるかに速くコードをテストするために使用できます。
- あなたの関数、クラス、モジュールのための適切なドキュメントを書く 。 PEP 257とGoogleのPython Style Guideは良いドキュメントストリングを書くための良い方法を提供しています。
- ロギングを使用して、開発中およびデプロイ後にプログラムから出力を生成します。
- 重要な場所でコードに
assert
イオンを追加assert
:あいまいさを減らし、問題が発生したときにそれを捕捉する。
ボーナス:ドキュメントとテストを組み合わせるためのdoctestを書く!