| Version 3 (modified by lfranc, 2 years ago) (diff) |
|---|
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
