wiki:Sistemismi

Version 4 (modified by fero, 3 years ago) (diff)

--

Riferimento utile oltre alla documentazione: Django Testing and debugging

Testare applicazioni Django

Un'applicazione Django è prima di tutto un'applicazione Python, per cui sono disponibili tutti gli strumenti e i framework di test sviluppati per il linguaggio Python, in particolare:

Entrambi questi strumenti hanno i loro punti di forza e debolezza: in generale, i doctests hanno il vantaggio di fungere anche da documentazione relativa all'utilizzo di un particolare componente software (funzione, classe, metodo, libreria,..); d'altra parte, soffrono di notevoli limitazioni tecniche, e sono poco adatti all'implementazione di test di una certa complessità; in questi casi, l'approccio più efficace e potente è quello di usare gli unittests.

La scrittura di doctests è quasi banale: basta digitare i comandi che si desiderano testare in una sessione interattiva e "copia-incollare" ciò che viene stampato a schermo (input e output, inclusi i prompt; la "traceback" non è necessaria) all'interno della docstring dell'unità di codice che si intende testare (e documentare).

La scrittura di unittests è invece più articolata: in estrema sintesi, gli unit tests vengono raggruppati in test cases a loro volta aggregati in test suites (questa operazione viene svolta automaticamente dal framework di test). Ogni test case è implementato come una sottoclasse di una classe base (TestCase); i test veri e propri sono i metodi di tale classe il cui nome inizia per test. Per l'esecuzione vera e propria dei test, il framework mette a disposizione un'insieme di metodi della classe TestCase (assertEqual, assertTrue, assertRaises, ..), che in genere verificano che un'asserzione risponda o meno alla realtà.

Quando il meccanismo di esecuzione dei test (test runner) viene invocato, gli unit tests così definiti vengono eseguiti, uno dopo l'altro, e viene riportato a schermo l'esito con cui sono conclusi:

  • OK: il test è stato passato con successo
  • FAIL: il test è fallito
  • ERROR: si è verificato un errore nel corso dell'esecuzione del test (un'eccezione Python che avviene al di fuori dei metodi di verifica messi a disposizione dal framework)

Per alcuni test, prima di eseguire le verifiche vere e proprie, è necessario configurare correttamente l'"ambiente" all'interno del quale il codice da testare verrà eseguito (ad esempio creazione di oggetti in memoria, inizializzazione di un db, ecc.); per questo scopo, nella classe TestCase sono disponibili i methodi setUp e tearDown, che vengono eseguiti rispettivamente *prima* e *dopo* l'esecuzione di ogni test.

Django mette a disposizione degli sviluppatori alcune estensioni al framework unittest, che comprendono:

  • una procedura che crea automaticamente un db di test prima dell'esecuzione di ogni TestCase (e lo distugge al termine)
  • alcune "asserzioni" specifiche per le problematiche dello svilupo web, come ad es:
    • verificare se un dato template è stato usato per una vista
    • verificare se l'output di una vista contiene una determinata stringa
    • ..

La problematica del testing di applicazioni Django viene discussa nel dettaglio in  questa pagina di manuale; in particolare, vengono trattati sia i  doctest, che gli  unittest; molto utile è anche il  client HTTP fittizio che può essere usato per simulare l'interazione con gli utenti.

Installing PIL on a virtual environment

Note: these instructions refer to a Debian-like operating system (specifically, they were tested on Ubuntu 10.04)

 PIL (Python Imaging Library) is an image-processing library needed by Django ImageFields. To install PIL under a virtual environment created with the --no-site-packages option, first install the Python development libraries:

$ sudo apt-get install python-dev

then use pip, as usual (after activating the virtualenv):

$ pip install pil