Django
felsökning
Sök…
Anmärkningar
Pdb
Pdb kan också skriva ut alla befintliga variabler i global eller lokal omfattning genom att skriva globals() eller locals() i (Pdb) -prompt respektive.
Använda Python Debugger (Pdb)
Det mest grundläggande Django-felsökningsverktyget är pdb , en del av Python standardbibliotek.
Init-skript
Låt oss undersöka ett enkelt views.py skript:
from django.http import HttpResponse
def index(request):
foo = 1
bar = 0
bug = foo/bar
return HttpResponse("%d goes here." % bug)
Konsolkommando för att köra server:
python manage.py runserver
Det är uppenbart att Django skulle kasta en ZeroDivisionError när du försöker ladda indexsidan, men om vi låtsas att felet är väldigt djupt i koden kan det bli riktigt otäckt.
Ställa in en brytpunkt
Lyckligtvis kan vi ställa in en brytpunkt för att spåra det felet:
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)
Konsolkommando för att köra server med pdb:
python -m pdb manage.py runserver
Nu på sidan belastning brytpunkt kommer att utlösa (Pdb) prompt i skalet, som också kommer att hänga din webbläsare i väntande tillstånd.
Felsökning med pdb-skal
Det är dags att felsöka den vyn genom att interagera med skript via shell:
> ../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
I den sista raden ser vi att vår åsikt gav ett OK svar och körs som det borde.
För att stoppa pdb-loopen, mata bara in q i ett skal.
Använda Django Debug Toolbar
Först måste du installera django-debug-toolbar :
pip install django-debug-toolbar
settings.py :
Därefter inkluderar den till projektets installerade appar, men var försiktig - det är alltid en bra praxis att använda en annan settings.py fil för sådana appar som bara är utvecklade och mellanvaror som felsökningsverktygsfält:
# If environment is dev...
DEBUG = True
INSTALLED_APPS += [
'debug_toolbar',
]
MIDDLEWARE += ['debug_toolbar.middleware.DebugToolbarMiddleware']
Debug-verktygsfältet förlitar sig också på statiska filer, så lämplig app bör också inkluderas:
INSTALLED_APPS = [
# ...
'django.contrib.staticfiles',
# ...
]
STATIC_URL = '/static/'
# If environment is dev...
DEBUG = True
INSTALLED_APPS += [
'debug_toolbar',
]
I vissa fall är det också nödvändigt att ställa in INTERNAL_IPS i settings.py :
INTERNAL_IPS = ('127.0.0.1', )
urls.py :
I urls.py , som officiell dokumentation antyder, ska nästa utdrag aktivera felsökning av verktygsfält:
if settings.DEBUG and 'debug_toolbar' in settings.INSTALLED_APPS:
import debug_toolbar
urlpatterns += [
url(r'^__debug__/', include(debug_toolbar.urls)),
]
Samla verktygsfältets statiska efter installationen:
python manage.py collectstatic
Det är det, felsökningsverktygsfältet kommer att visas på projektets sidor, med olika användbar information om körningstid, SQL, statiska filer, signaler etc.
HTML:
Dessutom django-debug-toolbar en innehållstyp av text/html , <html> och <body> taggar för att visas korrekt.
Om du är säker på att du har konfigurerat allt rätt men felsökningsverktygsfältet fortfarande inte återges: använd den här "kärnkraftslösningen" för att försöka ta reda på det.
Använda "hävda falskt"
När du utvecklar sätter du in följande rad i din kod:
assert False, value
kommer att få django att höja en AssertionError med värdet som levereras som ett felmeddelande när den här raden körs.
Om detta inträffar i en vy, eller i någon kod som anropas från en vy, och DEBUG=True är inställd, kommer en fullständig och detaljerad stacktrace med mycket felsökningsinformation att visas i webbläsaren.
Glöm inte att ta bort linjen när du är klar!
Överväg att skriva mer dokumentation, test, loggning och påståenden istället för att använda en felsökare
Felsökning tar tid och ansträngning.
Istället för att jaga buggar med en felsökare, kan du överväga att spendera mer tid på att göra din kod bättre genom att:
- Skriv och kör tester . Python och Django har fantastiska inbyggda testramar - som kan användas för att testa din kod mycket snabbare än manuellt med en felsökare.
- Skriva korrekt dokumentation för dina funktioner, klasser och moduler. PEP 257 och Googles Python Style Guide tillhandahåller god praxis för att skriva bra dokumentationer.
- Använd loggning för att producera output från ditt program - under utveckling och efter implementering.
- Lägg till
asserttill din kod på viktiga platser: Minska oklarhet, fånga problem när de skapas.
Bonus: Skriv doktor för att kombinera dokumentation och test!
