Ce tutoriel commence là où le tutoriel 4 s’est achevé. Nous avons construit une application Web de sondage et nous allons maintenant créer quelques tests automatisés pour cette application.
\n\nLes tests sont des routines qui vérifient le fonctionnement de votre code.
\nLes tests peuvent se faire à différents niveaux. Certains tests s’appliquent à un petit détail (est-ce que tel modèle renvoie les valeurs attendues ?), alors que d’autres examinent le fonctionnement global du logiciel (est-ce qu’une suite d’actions d’un utilisateur sur le site produit le résultat désiré ?). C’est le même genre de test qui a été pratiqué précédemment dans le tutoriel 2, en utilisant le shell pour examiner le comportement d’une méthode ou en lançant l’application et en saisissant des données pour contrôler son comportement.
Ce qui est différent dans les tests automatisés, c’est que le travail du test est fait pour vous par le système. Vous créez une seule fois un ensemble de tests, puis au fur et à mesure des modifications de votre application, vous pouvez contrôler que votre code fonctionne toujours tel qu’il devrait, sans devoir effectuer des tests manuels fastidieux.
\nAinsi donc, pourquoi créer des tests, et pourquoi maintenant ?
\nVous pouvez penser que vous avez déjà assez de chats à fouetter en apprenant Python/Django et que rajouter encore une nouvelle chose à apprendre et à faire est superflu et inutile. Après tout, notre application de sondage fonctionne maintenant à satisfaction ; se préoccuper encore de créer des tests automatisés ne va pas l’améliorer. Si la création de l’application de sondage est la dernière œuvre de programmation Django que vous entreprenez, alors oui, vous pouvez vous passer d’apprendre à créer des tests automatisés. Mais si ce n’est pas le cas, alors c’est maintenant l’occasion d’apprendre cela.
\nJusqu’à un certain point, « contrôler que cela fonctionne apparemment » est un test satisfaisant. Dans une application plus sophistiquée, vous pouvez rencontrer des dizaines d’interactions complexes entre les différents composants.
\nUne modification dans n’importe lequel de ces composants pourrait avoir des conséquences inattendues sur le comportement de l’application. Contrôler que « cela semble marcher » pourrait signifier la vérification de vingt combinaisons différentes de données de test pour être sûr que vous n’avez rien cassé - vous avez certainement mieux à faire.
\nC’est particulièrement vrai alors que des tests automatisés pourraient faire cela pour vous en quelques secondes. Si quelque chose se passe mal, les tests vous aideront à identifier le code qui produit le comportement inapproprié.
\nParfois, le fait de laisser de côté votre productif et créatif travail de programmation pour affronter la tâche ingrate et peu motivante de l’écriture de tests, peut ressembler à une corvée, spécialement lorsque vous savez que votre code fonctionne correctement.
\nCependant, l’écriture de tests est bien plus rentable que de passer des heures à tester manuellement votre application ou à essayer d’identifier la cause d’un problème récemment découvert.
\nC’est une erreur de penser que les tests ne sont que l’aspect négatif du développement.
\nSans tests, le but ou le comportement attendu d’une application pourrait rester obscur. Même quand il s’agit de votre propre code, vous vous retrouverez parfois à fouiner un peu partout pour retrouver ce qu’il fait au juste.
\nLes tests changent cela ; ils éclairent votre code de l’intérieur et lorsque quelque chose va de travers, ils mettent en relief la partie qui coince, même lorsque vous n’avez même pas réalisé que quelque chose n’allait pas.
\nVous avez peut-être créé un bout de logiciel extraordinaire, mais vous constaterez que beaucoup d’autres développeurs vont refuser de l’examiner parce qu’il ne contient pas de tests ; sans tests, ils ne lui font pas confiance. Jacob Kaplan-Moss, l’un des développeurs initiaux de Django, a dit : « Du code sans tests est par définition du code cassé ».
\nLe fait que d’autres développeurs veulent voir des tests dans votre logiciel avant de le prendre au sérieux est une raison supplémentaire de commencer l’écriture de tests.
\nLes points précédents sont écrits du point de vue d’un développeur isolé maintenant une application. Les applications complexes sont maintenues par des équipes. Les tests garantissent que les collègues ne cassent votre code par mégarde (et aussi que vous ne cassiez le leur sans le vouloir). Si vous voulez gagner votre vie en tant que programmeur Django, vous devez être bon dans l’écriture de tests !
\nIl existe de nombreuses approches pour écrire des tests.
\nCertains programmeurs suivent une discipline appelée « développement piloté par les tests » (test-driven development <http://fr.wikipedia.org/wiki/Test_Driven_Development>). Ils écrivent les tests avant de commencer à écrire le code. Cela peut paraître illogique, mais c’est un processus très semblable à ce que la plupart des gens font : ils décrivent un problème, puis ils écrivent du code pour le résoudre. Le développement piloté par les tests formalise le problème dans un cas de test Python.
\nPlus souvent, un débutant dans les tests va créer du code, puis il décidera plus tard qu’il devrait ajouter des tests. Il aurait peut-être été préférable d’écrire des tests plus tôt, mais il n’est jamais trop tard pour commencer.
\nIl est parfois difficile de trouver où commencer en écrivant des tests. Si vous avez écrit plusieurs milliers de lignes de code Python, choisir quoi tester n’est pas simple. Dans un tel cas, il peut être utile d’écrire le premier test au moment où vous effectuez votre prochaine modification, soit pour ajouter une nouvelle fonctionnalité ou pour corriger un bogue.
\nEntrons dans le vif du sujet.
\nHeureusement, il y a un petit bogue dans l’application polls, tout prêt à être corrigé : la méthode Question.was_published_recently() renvoie True si l’objet Question a été publié durant le jour précédent (ce qui est correct), mais également si le champ pub_date de Question est dans le futur (ce qui n’est évidemment pas juste).
Confirmez l’existence du bogue en utilisant le shell pour contrôler la méthode sur une question dont la date se situe dans le futur :
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> import datetime\n>>> from django.utils import timezone\n>>> from polls.models import Question\n>>> # create a Question instance with pub_date 30 days in the future\n>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))\n>>> # was it published recently?\n>>> future_question.was_published_recently()\nTrue\nÉtant donné que ce qui est dans le futur n’est pas « récent », c’est clairement une erreur.
\nCe que nous venons de faire dans le shell pour tester le problème est exactement ce que nous pouvons faire dans un test automatisé ; transformons cette opération en un test automatisé.
Un endroit conventionnel pour placer les tests d’une application est le fichier tests.py dans le répertoire de l’application. Le système de test va automatiquement trouver les tests dans tout fichier dont le nom commence par test.
Placez ce qui suit dans le fichier tests.py de l’application polls:
import datetime\n\nfrom django.test import TestCase\nfrom django.utils import timezone\n\nfrom .models import Question\n\n\nclass QuestionModelTests(TestCase):\n\n def test_was_published_recently_with_future_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is in the future.\n """\n time = timezone.now() + datetime.timedelta(days=30)\n future_question = Question(pub_date=time)\n self.assertIs(future_question.was_published_recently(), False)\nNous venons ici de créer une sous-classe de django.test.TestCase contenant une méthode qui crée une instance Question en renseignant pub_date dans le futur. Nous vérifions ensuite le résultat de was_published_recently() qui devrait valoir False.
Dans le terminal, nous pouvons lancer notre test :
\nLinux / macOS
$ python manage.py test polls\nWindows
...\\> py manage.py test polls\net vous devriez voir quelque chose comme :
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\nF\n======================================================================\nFAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question\n self.assertIs(future_question.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nFAILED (failures=1)\nDestroying test database for alias 'default'...\nVoici ce qui s’est passé :
\nLa commande manage.py test polls a cherché des tests dans l’application polls ;
elle a trouvé une sous-classe de django.test.TestCase ;
elle a créé une base de données spéciale uniquement pour les tests ;
elle a recherché des méthodes de test, celles dont le nom commence par test ;
dans test_was_published_recently_with_future_question, elle a créé une instance Question dont le champ pub_date est 30 jours dans le futur ;
… et à l’aide de la méthode assertIs(), elle a découvert que sa méthode was_published_recently() renvoyait True, alors que nous souhaitions qu’elle renvoie False.
Le test nous indique le nom du test qui a échoué ainsi que la ligne à laquelle l’échec s’est produit.
\nNous connaissons déjà le problème : Question.was_published_recently() devrait renvoyer False si sa pub_date est dans le futur. Corrigez la méthode dans models.py afin qu’elle ne renvoie True que si la date est aussi dans le passé :
def was_published_recently(self):\n now = timezone.now()\n return now - datetime.timedelta(days=1) <= self.pub_date <= now\npuis lancez à nouveau le test :
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\n.\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nOK\nDestroying test database for alias 'default'...\nAprès avoir identifié un bogue, nous avons écrit un test qui le révèle et nous avons corrigé l’erreur dans le code pour que notre test réussisse.
\nBien d’autres choses pourraient aller de travers avec notre application à l’avenir, mais nous pouvons être sûrs que nous n’allons pas réintroduire cette erreur par mégarde, car en lançant le test, nous serons immédiatement avertis. Nous pouvons considérer que cette petite partie de l’application est assurée de rester fonctionnelle pour toujours.
\nPendant que nous y sommes, nous pouvons assurer un peu plus le fonctionnement de la méthode was_published_recently() ; en fait, il serait réellement embarrassant si en corrigeant un bogue, nous en avions introduit un autre.
Ajoutez deux méthodes de test supplémentaires dans la même classe pour tester le comportement de la méthode de manière plus complète :
\ndef test_was_published_recently_with_old_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is older than 1 day.\n """\n time = timezone.now() - datetime.timedelta(days=1, seconds=1)\n old_question = Question(pub_date=time)\n self.assertIs(old_question.was_published_recently(), False)\n\ndef test_was_published_recently_with_recent_question(self):\n """\n was_published_recently() returns True for questions whose pub_date\n is within the last day.\n """\n time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)\n recent_question = Question(pub_date=time)\n self.assertIs(recent_question.was_published_recently(), True)\nEt maintenant nous disposons de trois tests qui confirment que Question.was_published_recently() renvoie des valeurs correctes pour des questions passées, récentes et futures.
Encore une fois, polls est une application minimale, mais quelle que soit la complexité de son évolution ou le code avec lequel elle devra interagir, nous avons maintenant une certaine garantie que la méthode pour laquelle nous avons écrit des tests se comportera de façon cohérente.
L’application de sondage est peu regardante : elle publiera toute question, y compris celles dont le champ pub_date est situé dans le futur. C’est à améliorer. Définir pub_date dans le futur devrait signifier que la question sera publiée à ce moment, mais qu’elle ne doit pas être visible avant cela.
En corrigeant le bogue ci-dessus, nous avons d’abord écrit le test, puis le code pour le corriger. En fait, c’était un exemple de développement piloté par les tests, mais l’ordre dans lequel se font les choses n’est pas fondamental.
\nDans notre premier test, nous nous sommes concentrés étroitement sur le fonctionnement interne du code. Pour ce test, nous voulons contrôler son comportement tel qu’il se déroulerait avec un utilisateur depuis son navigateur.
\nAvant d’essayer de corriger quoi que ce soit, examinons les outils à notre disposition.
\nDjango fournit un Client de test pour simuler l’interaction d’un utilisateur avec le code au niveau des vues. On peut l’utiliser dans tests.py ou même dans le shell.
Nous commencerons encore une fois par le shell, où nous devons faire quelques opérations qui ne seront pas nécessaires dans tests.py. La première est de configurer l’environnement de test dans le shell:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> from django.test.utils import setup_test_environment\n>>> setup_test_environment()\nsetup_test_environment() installe un moteur de rendu de gabarit qui va nous permettre d’examiner certains attributs supplémentaires des réponses, tels que response.context qui n’est normalement pas disponible. Notez que cette méthode ne crée pas de base de données de test, ce qui signifie que ce qui suit va être appliqué à la base de données existante et que par conséquent, le résultat peut légèrement différer en fonction des questions que vous avez déjà créées. Si le réglage TIME_ZONE dans settings.py n’est pas correct, il se peut que certains résultats soient faussés. Si vous n’avez pas pensé à le régler précédemment, vérifiez-le avant de continuer.
Ensuite, il est nécessaire d’importer la classe Client de test (plus loin dans tests.py, nous utiliserons la classe django.test.TestCase qui apporte son propre client, ce qui évitera cette étape) :
>>> from django.test import Client\n>>> # create an instance of the client for our use\n>>> client = Client()\nCeci fait, nous pouvons demander au client de faire certaines tâches pour nous :
\n>>> # get a response from '/'\n>>> response = client.get('/')\nNot Found: /\n>>> # we should expect a 404 from that address; if you instead see an\n>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably\n>>> # omitted the setup_test_environment() call described earlier.\n>>> response.status_code\n404\n>>> # on the other hand we should expect to find something at '/polls/'\n>>> # we'll use 'reverse()' rather than a hardcoded URL\n>>> from django.urls import reverse\n>>> response = client.get(reverse('polls:index'))\n>>> response.status_code\n200\n>>> response.content\nb'\\n <ul>\\n \\n <li><a href="/polls/1/">What's up?</a></li>\\n \\n </ul>\\n\\n'\n>>> response.context['latest_question_list']\n<QuerySet [<Question: What's up?>]>\nLa liste des sondages montre aussi les sondages pas encore publiés (c’est-à-dire ceux dont le champ pub_date est dans le futur). Corrigeons cela.
Dans le tutoriel 4, nous avons introduit une vue basée sur la classe ListView:
class IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\nNous devons corriger la méthode get_queryset() pour qu’elle vérifie aussi la date en la comparant avec timezone.now(). Nous devons d’abord ajouter une importation :
from django.utils import timezone\npuis nous devons corriger la méthode get_queryset de cette façon :
def get_queryset(self):\n """\n Return the last five published questions (not including those set to be\n published in the future).\n """\n return Question.objects.filter(\n pub_date__lte=timezone.now()\n ).order_by('-pub_date')[:5]\nQuestion.objects.filter(pub_date__lte=timezone.now()) renvoie un queryset contenant les questions dont le champ pub_date est plus petit ou égal (c’est-à-dire plus ancien ou égal) à timezone.now.
Vous pouvez maintenant vérifier vous-même que tout fonctionne comme prévu en lançant runserver et en accédant au site depuis votre navigateur. Créez des questions avec des dates dans le passé et dans le futur et vérifiez que seuls celles qui ont été publiées apparaissent dans la liste. Mais vous ne voulez pas faire ce travail de test manuel chaque fois que vous effectuez une modification qui pourrait affecter ce comportement, créons donc aussi un test basé sur le contenu de notre session shell précédente.
Ajoutez ce qui suit à polls/tests.py:
from django.urls import reverse\net nous allons créer une fonction raccourci pour créer des questions, ainsi qu’une nouvelle classe de test :
\ndef create_question(question_text, days):\n """\n Create a question with the given `question_text` and published the\n given number of `days` offset to now (negative for questions published\n in the past, positive for questions that have yet to be published).\n """\n time = timezone.now() + datetime.timedelta(days=days)\n return Question.objects.create(question_text=question_text, pub_date=time)\n\n\nclass QuestionIndexViewTests(TestCase):\n def test_no_questions(self):\n """\n If no questions exist, an appropriate message is displayed.\n """\n response = self.client.get(reverse('polls:index'))\n self.assertEqual(response.status_code, 200)\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_past_question(self):\n """\n Questions with a pub_date in the past are displayed on the\n index page.\n """\n create_question(question_text="Past question.", days=-30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_future_question(self):\n """\n Questions with a pub_date in the future aren't displayed on\n the index page.\n """\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_future_question_and_past_question(self):\n """\n Even if both past and future questions exist, only past questions\n are displayed.\n """\n create_question(question_text="Past question.", days=-30)\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_two_past_questions(self):\n """\n The questions index page may display multiple questions.\n """\n create_question(question_text="Past question 1.", days=-30)\n create_question(question_text="Past question 2.", days=-5)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question 2.>', '<Question: Past question 1.>']\n )\nExaminons plus en détails certaines de ces méthodes.
\nTout d’abord, la fonction raccourci create_question permet d’éviter de répéter plusieurs fois le processus de création de questions.
test_no_questions ne crée aucune question, mais vérifie le message : « No polls are available. » et que la liste latest_question_list est vide. Notez que la classe django.test.TestCase fournit quelques méthodes d’assertion supplémentaires. Dans ces exemples, nous utilisons assertContains() et assertQuerysetEqual().
Dans test_past_question, nous créons une question et vérifions qu’elle apparaît dans la liste.
Dans test_future_question, nous créons une question avec pub_date dans le futur. La base de données est réinitialisée pour chaque méthode de test, ce qui explique que la première question n’est plus disponible et que la page d’index n’affiche plus de question.
Et ainsi de suite. En pratique, nous utilisons les tests pour raconter des histoires d’interactions entre des saisies dans l’interface d’administration et d’un utilisateur parcourant le site, en contrôlant qu’à chaque état ou changement d’état du système, les résultats attendus apparaissent.
\nDetailViewLien vers cette rubrique#Le code marche bien maintenant. Cependant, même si les questions futures n’apparaissent pas sur la page index, les utilisateurs peuvent toujours y accéder s’ils savent ou devinent la bonne URL. Nous avons donc besoin d’une contrainte semblable dans DetailView :
class DetailView(generic.DetailView):\n ...\n def get_queryset(self):\n """\n Excludes any questions that aren't published yet.\n """\n return Question.objects.filter(pub_date__lte=timezone.now())\nIl est ensuite nécessaire d’ajouter quelques tests, pour contrôler qu’une question dont pub_date est dans le passé peut être affichée, mais que si pub_date est dans le futur, elle ne le sera pas :
class QuestionDetailViewTests(TestCase):\n def test_future_question(self):\n """\n The detail view of a question with a pub_date in the future\n returns a 404 not found.\n """\n future_question = create_question(question_text='Future question.', days=5)\n url = reverse('polls:detail', args=(future_question.id,))\n response = self.client.get(url)\n self.assertEqual(response.status_code, 404)\n\n def test_past_question(self):\n """\n The detail view of a question with a pub_date in the past\n displays the question's text.\n """\n past_question = create_question(question_text='Past Question.', days=-5)\n url = reverse('polls:detail', args=(past_question.id,))\n response = self.client.get(url)\n self.assertContains(response, past_question.question_text)\nNous devrions ajouter une méthode get_queryset similaire à ResultsView et créer une nouvelle classe de test pour cette vue. Elle sera très semblable à celle que nous venons de créer ; en fait, il y aura beaucoup de répétition.
Nous pourrions aussi améliorer notre application d’autres manières, en ajoutant des tests au fur et à mesure. Par exemple, il est stupide de pouvoir publier des questions sur le site sans choix. Nos vues pourraient donc vérifier cela et exclure de telles questions. Les tests créeraient une question sans choix et testeraient qu’elle n’est pas publiée ; de même, il s’agirait de créer une question avec des choix et tester qu’elle est bien publiée.
\nPeut-être que les utilisateurs connectés dans l’interface d’administration pourraient être autorisés à voir les questions non publiées, mais pas les visiteurs ordinaires. C’est toujours le même principe, tout ce qui est ajouté au logiciel devrait être accompagné par un test, que ce soit en écrivant d’abord le test puis en écrivant le code pour réussir le test, ou en travaillant d’abord sur la logique du code et en écrivant ensuite le test pour prouver le bon fonctionnement.
\nÀ un certain stade, vous allez regarder vos tests et vous demander si votre code ne souffre pas de surabondance de tests, ce qui nous amène à :
\nEn apparence, les tests peuvent avoir l’air de croître sans limites. À ce rythme, il y aura bientôt plus de code dans nos tests que dans notre application ; et la répétition est laide, comparée à la brièveté élégante du reste du code.
\nÇa n’a aucune importance. Laissez-les grandir. Dans la plupart des cas, vous pouvez écrire un test une fois et ne plus y penser. Il continuera à jouer son précieux rôle tout au long du développement de votre programme.
\nLes tests devront parfois être mis à jour. Supposons que nous corrigeons nos vues pour que seules les questions avec choix soient publiées. Dans ce cas, de nombreux tests existants vont échouer, ce qui nous informera exactement au sujet des tests qui devront être mis à jour ; dans cette optique, on peut dire que les tests prennent soin d’eux-même.
\nAu pire, au cours du développement, vous pouvez constater que certains tests deviennent redondants. Ce n’est même pas un problème. Dans les tests, la redondance est une bonne chose.
\nTant que vos tests sont logiquement disposés, ils ne deviendront pas ingérables. Quelques bons principes à garder en tête :
\nune classe de test séparée pour chaque modèle ou vue ;
une méthode de test séparée pour chaque ensemble de conditions que vous voulez tester ;
des noms de méthodes de test qui indiquent ce qu’elles font.
Ce tutoriel ne fait qu’introduire à quelques concepts de base des tests. Il y a encore beaucoup plus à faire et d’autres outils très utiles à votre disposition pour effectuer des choses plus perfectionnées.
\nPar exemple, bien que les tests présentés ici couvrent une partie de la logique interne d’un modèle et la manière dont les vues publient de l’information, vous pouvez utiliser un système basé sur de vrais navigateurs comme Selenium pour tester la façon dont le code HTML est vraiment rendu dans un navigateur. Ces outils permettent de tester plus que le comportement du seul code Django, mais aussi, par exemple, du code JavaScript. C’est assez impressionnant de voir les tests lancer un navigateur et commencer d’interagir avec votre site, comme si un être humain invisible le pilotait ! Django propose la classe LiveServerTestCase pour faciliter l’intégration avec des outils comme Selenium.
Si votre application est complexe, il peut être utile de lancer automatiquement les tests lors de chaque commit dans l’optique d’une intégration continue), afin que le contrôle qualité puisse être lui-même automatisé, au moins partiellement.
\nUne bonne façon de détecter des parties d’application non couvertes par les tests est de contrôler la couverture du code. Cela aide aussi à identifier du code fragile, ou même mort. Si vous ne pouvez pas tester un bout de code, cela signifie généralement que le code doit être réarrangé ou supprimé. Le taux de couverture aide à identifier le code inutilisé. Consultez Intégration avec coverage.py pour plus de détails.
\nDjango et les tests contient des informations complètes au sujet des tests.
\nPour des détails complets sur les tests, consultez Django et les tests.
\nLorsque vous êtes à l’aise avec les tests de vues Django, lisez la 6ème partie de ce tutoriel pour en savoir plus sur la gestion des fichiers statiques.
\n