Damien MATHIEU

Après avoir vu la mise en place de l’environnement de test et des tests unitaires avec Django, voyons maintenant comment mettre en place nos tests fonctionnels.
En écrivant cet article, je considère que vous avez lu l’article précédent et que vous avez donc compris ma méthode de hiérarchisation des tests.

Voici un test d’exemple (j’allais dire « de test ». Mais c’est un chouilla trop répétitif).
from django.test import TestCase
from django.test.client import Client
from projet.pages.models import Pager
class PagesTest(TestCase):
  def setUp(self):
    self.client = Client()
  def test_view_page(self):
    Page(
      name='Conditions d\'utilisation',
      url='conditions',
      content='nothing for now'
    ).save()
    response = self.client.get('/conditions')
    self.failUnlessEqual(response.status_code, 200)
  def test_view_unknown_page(self):
    response = self.client.get('/nothing/')
    self.failUnlessEqual(response.status_code, 404)

Et analysons le code.
Nous commençons par importer les diverse classes nécessaires à ces tests :

• TestCase, le framework de test
• Client, le client HTTP de test
• Page, le modèle qui nous permet d’ajouter des données permettant ici les tests

Puis nous commençons les tests, en initialisant self.client à une nouvelle instance de Client afin de pouvoir faire des requêtes HTTP.
Dans le premier test, nous créons un élément Page puis nous testons que lorsque nous appellons celui-ci, notre page est bien rendue.
Et dans le second, nous vérifions que nous avons une bien une erreur 404 si nous appellons une page qui n’existe pas.

Vous noterez la méthode self.client.get() permettant de faire un appel HTTP avec la méthode du même nom.

Plusieurs méthodes sont ainsi disponibles pour faire les appels HTTP.

• get(path, data={}, follow=False) – Fait une requête HTTP get
• post(path, data={}, follow=False) – Fait une requête HTTP post
• head(path, data={}, follow=False) – Fait une requête HTTP head
• options(path, data={}, follow=False) – Fait une requête HTTP options
• put(path, data={}, follow=False) – Fait une requête HTTP put
• delete(path, data={}, follow=False) – Fait une requête HTTP delete

A cela s’ajoutent deux méthodes permettant d’identifier et de déconnecter l’utilisateur.

• login(options) – Identifie l’utilisateur et retourne true si celle-ci a réussi.
  Exemple : self.client.login(username='test', password='test')
• logout() – Déconnecte l’utilisateur auparavant connecté

Lorsque vous faites une requête quelconque, vous pouvez en tester le résultat. Voici les différentes méthodes disponibles.

• client – Le client de test qui a été utilisé pour faire la requête
• content – Le contenu de la page rendue
• context – L’instance de la classe Context qui a été utilisée pour afficher le contenu de la page. Si il y a eu plusieurs templates de rendus, il s’agira d’une liste de contextes triés par ordre de rendu.
• request – Les données request qui ont servi à faire la requête
• status_code – Le code HTTP retourné par la page
• template – L’instance de template qui a été utilisée afin d’afficher le contenu de la page. Si il y en a eu plusieurs, un tableau de templates triés par ordre d’affichage sera retourné.

Du coup vous avez maintenant toutes les clés en main pour commencer à faire vos tests fonctionnels. Y’a plus qu’à coder !

Par défaut, Django inclue deux frameworks de tests différents. Le premier, Doctest, impose de placer ses tests dans une chaine de caractères.
Le second, Unit Tests, est plus conventionnel et requiert de créer une méthode pour chacun de nos tests.
Le premier nous faisant perdre toute colorisation syntaxique, nous allons donc voir uniquement le second dans cet article.

Chacune de vos applications Django peut prendre des tests. Ceux-ci sont exécutés avec la commande manage.py tests
Qui va exécuter, pour chaque application, toutes les méthodes contenues dans le fichier tests.py de votre application.

Bien évidemment, placer tous nos tests dans ce fichier serait illisible.
Créons donc notre architecture de test :
|- application
|– tests.py
|– test
|— functional
|—- my_functional_test.py
|— unit
|—- my_unit_test.py

Nous séparons donc nos tests unitaires et fonctionnels et permettons de créer plusieurs fichiers pour chaque si nous le désirons.
Puis dans tests.py, il faut les inclure ces fichiers.
from project.application.test.functional.my_test import HomepageTests
from project.application.test.unit.my_test import UserTests

Remplissons maintenant nos tests unitaires.
Dans chaque fichier de test, nous devons faire appel au framework approprié en haut de page.
from django.test import TestCase

Puis nous créons la méthode UserTests, importée plus haut et qui contiendra nos tests.
class SimpleTest(TestCase):
  def test_basic_addition(self):
    self.failUnlessEqual(1 + 1, 2)
Nous testons ici que 1 + 1 est bien égal à 2. A vous par la suite de créer vos tests selon vos besoins.

Les méthodes permettant de faire les tests sont les suivantes :

• setUp() – Méthode appellée pour préparer les fixtures des tests et donc avant ceux-ci. Il est inutile de l’appeller. En revanche, vous pouvez la surcharger.
• tearDown() – Méthode appellée après que le test ait été exécuté (qu’il ait réussi ou non).
• assertTrue(expression, message) – Vérifie que l’expression est bien égale à vrai.
• assertEqual(first, second, message) – Vérifie que la première expression est égale à la seconde
• failUnlessEqual(first, second, message) – Alias de assertEqual
• assertNotEqual(first, second, message) – Vérifie que la première expression est différente de la seconde
• failIfEqual(first, second, message) – Alias de assertNotEqual
• assertAlmostEqual(first, second, décimales, msg) – Vérifie que les deux valeurs sont approximativement égales en calculant leur différence, puis l’arrondit à son nombre de décimales (défault : 7) et en les comparant à zéro.
• failUnlessAlmostEqual(first, second, décimales, msg) – Alias de assertAlmostEqual
• assertNotAlmostEquat(first, second, décimales, msg) – Vérifie que les deux valeurs sont approximativement égales en calculant leur différence, puis l’arrondit à son nombre de décimales (défault : 7) et en les comparant à zéro.
• failIfAlmostEqual(first, second, décimales, msg) – Alias de assertNotAlmostEqual
• assertRaises(exception, callable, …) – Vérifie qu’une exception a été levée. Le test passera si l’exception définie est levée et échouera si il s’agit d’une autre ou qu’aucune exception n’est levée
• failUnlessRaises(exception, callable) – Alias de assertRaises()
• failIf(expr, msg) – Opposé de failUnless
• assertFalse(expr, msg) – Alias de failIf
• fail(msg) – Retourne une erreur

Vous pouvez donc maintenant tester toutes les méthodes de vos modèles de manière efficace.
Vous pouvez donc continuer avec les tests fonctionnels.