Django
felsökning

AngularJS CSS HTML JavaScript jQuery MongoDB MySQL postgresql Python Language SQL
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 assert till din kod på viktiga platser: Minska oklarhet, fånga problem när de skapas.

Bonus: Skriv doktor för att kombinera dokumentation och test!



Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow