Outre les tests sur des méthodes, fonctions, etc., qui sont spécifiques, il est également possible de tester des vues. Cela se fait grâce à un serveur web intégré au système de test qui sera lancé tout seul lors de la vérification des tests.
Pour tester quelques vues, nous allons utiliser l'application mini_url créée lors du TP de la deuxième partie. N'hésitez pas à reprendre le code que nous avons donné en solution si ce n'est pas déjà fait, nous nous baserons sur celui-ci afin de construire nos tests.
Voici le début de notre mini_url/tests.py, incluant notre premier test :
Code : Python
#-*- coding: utf-8 -*-
from django.test import TestCase
from django.core.urlresolvers import reverse
from models import MiniURL
from views import generer
mini = MiniURL(url="http://foo.bar",code=generer(6), pseudo=u"Foo foo !")
mini.save() return mini
class MiniURLTests(TestCase): def test_liste(self): """
Vérifie si une URL sauvegardée est bien affichée """
mini = creer_url()
reponse = self.client.get(reverse('mini_url.views.liste')) self.assertEqual(reponse.status_code, 200)
self.assertContains(reponse, mini.url)
self.assertQuerysetEqual(reponse.context['minis'], [repr(mini)])
Nous avons créé une petite fonction nommée creer_url qui crée une redirection, l'enregistre et la retourne, afin de ne pas devoir dupliquer le code dans nos futurs tests.
Django créera à chaque séance de tests une nouvelle base de données vide et utilisera celle-ci, au lieu d'utiliser la base de données classique, afin d'éviter de compromettre cette dernière.
Intéressons-nous ensuite au test test_liste qui va s'assurer que lorsque nous créons une redirection dans la base de données celle-ci est bien affichée par la vue views.liste. Pour ce faire, nous créons tout d'abord une redirection grâce à la fonction creer_url et nous demandons ensuite au client intégré au système de test d'accéder à la vue liste grâce à la méthode get de self.client. Cette méthode prend une URL, c'est pourquoi nous utilisons la fonction reverse afin d'obtenir l'URL de la vue spécifiée.
get retourne un objet dont les principaux attributs sont status_code, un entier représentant le code HTTP de la réponse, content, une chaîne de caractères contenant le contenu de la réponse, et context, le dictionnaire de variables passé au template si un dictionnaire a été utilisé.
Nous pouvons donc vérifier si notre vue s'est bien exécutée en vérifiant le code HTTP de la réponse :
self.assertEqual(reponse.status_code, 200).
Pour rappel, 200 correspond à une requête correctement déroulée, 302 à une redirection, 404 à une page non trouvée et 500 à une erreur côté serveur.
Deuxième vérification : est-ce que l'URL qui vient d'être créée est bien affichée sur la page ? Cela se fait grâce à la méthode assertContains qui prend comme premier argument une réponse comme celle donnée par get, et en deuxième argument une chaîne de caractères. La méthode renvoie une erreur si la chaîne de caractères n'est pas contenue dans la page.
Dernière et troisième vérification : est-ce que le QuerySet minis contenant toutes les redirections dans notre vue (celui que nous avons passé à notre template et qui est accessible depuis reponse.context) est égal au QuerySet indiqué en deuxième paramètre ? En réalité, le deuxième argument n'est pas un QuerySet, mais est censé correspondre à la représentation du premier argument grâce à la fonction repr. Autrement dit, il faut que repr(premier_argument) ==
deuxieme_argument. Voici ce à quoi ressemble le deuxième argument dans notre exemple : ['<MiniURL: [ALSWM0] http://foo.bar>'].
Dans ce test, nous n'avons demandé qu'une simple page. Mais comment faire si nous souhaitons par exemple soumettre un formulaire ? Une telle opération se fait grâce à la méthode post de self.client, dont voici un exemple à partir de la vue nouveau de notre application, qui permet d'ajouter une redirection :
Code : Python
def test_nouveau_redirection(self): """
Vérifie la redirection d'un ajout d'URL """
data = {
'url':'http://www.siteduzero.com', 'pseudo':u'Un zéro',
}
reponse =
self.client.post(reverse('mini_url.views.nouveau'), data)
être une redirection
self.assertRedirects(reponse, reverse('mini_url.views.liste'))
La méthode post fonctionne comme get, si ce n'est qu'elle prend un deuxième argument, à savoir un dictionnaire contenant les informations du formulaire. De plus, nous avons utilisé ici une nouvelle méthode de vérification : assertRedirects, qui vérifie que la réponse est bien une redirection vers l'URL passée en paramètre. Autrement dit, si la requête s'effectue correctement, la vue nouveau doit rediriger l'utilisateur vers la vue liste.
Sachez que si vous gérez des redirections, vous pouvez forcer Django à suivre la redirection directement en indiquant
follow=True à get ou post, ce qui fait que la réponse ne contiendra pas la redirection en elle-même, mais la page ciblée par la redirection, comme le montre l'exemple suivant.
Code : Python
def test_nouveau_ajout(self): """
Vérifie si après la redirection l'URL ajoutée est bien dans la liste
"""
data = {
'url':'http://www.crepes-bretonnes.com', 'pseudo':u'Amateur de crêpes',
}
reponse =
self.client.post(reverse('mini_url.views.nouveau'), data, follow=True)
self.assertEqual(reponse.status_code, 200) self.assertContains(reponse, data['url'])
Dernier cas de figure à aborder : imaginons que vous souhaitiez tester une vue pour laquelle il faut obligatoirement être connecté à partir d'un compte utilisateur, sachez que vous pouvez vous connecter et vous déconnecter de la façon suivante :
Code : Python
c = Client()
c.login(username='utilisateur', password='mot_de_passe') reponse = c.get('/une/url/')
c.logout() # La déconnexion n'est pas obligatoire
En résumé
Les tests unitaires permettent de s'assurer que vous n'avez introduit aucune erreur lors de votre développement, et assurent la robustesse de votre application au fil du temps.
Les tests sont présentés comme une suite de fonctions à exécuter, testant plusieurs assertions. En cas d'échec d'une seule assertion, il est nécessaire de vérifier son code (ou le code du test), qui renvoie un comportement anormal. Les tests sont réalisés sur une base de données différente de celles de développement ; il n'y a donc aucun souci de corruption de données lors de leur lancement.
Il est possible de tester le bon fonctionnement des modèles, mais aussi des vues. Ainsi, nous pouvons vérifier si une vue déclenche bien une redirection, une erreur, ou si l'enregistrement d'un objet a bien lieu.
Ouverture vers de nouveaux horizons :
django.contrib
Une des forces de Python est sa philosophie « batteries included » (littéralement « piles incluses ».) : la bibliothèque standard couvre un nombre d'utilisations très large, et permet d'intégrer énormément de fonctionnalités, sans qu'on doive les coder entièrement une à une. Django suit également cette philosophie, en incluant dans le framework un nombre de modules complémentaires très important.
Nous arrivons à la fin de ce cours, nous vous proposons donc de parcourir rapidement la liste de ces modules, afin de découvrir d'éventuels modules qui pourraient vous intéresser.