From d596e86a4f13b04981f51d327af257b07e6d21c3 Mon Sep 17 00:00:00 2001 From: SphinxKnight Date: Sun, 14 Nov 2021 14:23:22 +0100 Subject: Prepare Learning Area section for Markdown conversion (#2738) * Remove summary, spans and fonts * Remove notranslate class * Remove ids other than headings * Remove hidden blocks * fix livesample call with exclamation mark * fix livesample call with exclamation mark * fix livesample call with exclamation mark * fix livesample call with exclamation mark * Fix notes * Remove code in pre, sub/sup and some styles * fix dls * fix absolute / english links * fix figures and others * fix other issues from report * Fix other one-off issues excl. imgs * Fix images * Fixes #2842 for Learning area --- .../fr/learn/server-side/django/testing/index.html | 64 +++++++++++----------- 1 file changed, 32 insertions(+), 32 deletions(-) (limited to 'files/fr/learn/server-side/django/testing/index.html') diff --git a/files/fr/learn/server-side/django/testing/index.html b/files/fr/learn/server-side/django/testing/index.html index ab06d584ec..c61cb87e24 100644 --- a/files/fr/learn/server-side/django/testing/index.html +++ b/files/fr/learn/server-side/django/testing/index.html @@ -17,13 +17,13 @@ translation_of: Learn/Server-side/Django/Testing
{{PreviousMenuNext("Learn/Server-side/Django/Forms", "Learn/Server-side/Django/Deployment", "Learn/Server-side/Django")}}
-

Quant un site web grandit, il devient plus difficile à tester manuellement. Non seulement il y a plus de choses à tester, mais encore, comme les interactions entres ses composants deviennent plus complexes, un léger changement dans une partie de l'application peut affecter les autres parties, si bien qu'il va être nécessaire de faire beaucoup de modifications pour s'assurer que tout continue de fonctionner, et qu'aucune erreur ne sera introduite quand il y aura encore plus de modifications. Une façon de limiter ces problèmes est d'écrire des tests automatiques qui puissent être lancés d'une manière simple et fiable à chaque fois que vous faites une modification. Ce tutoriel montre comment automatiser des tests unitaires sur votre site web en utilisant le framework de tests de Django.

+

Quant un site web grandit, il devient plus difficile à tester manuellement. Non seulement il y a plus de choses à tester, mais encore, comme les interactions entres ses composants deviennent plus complexes, un léger changement dans une partie de l'application peut affecter les autres parties, si bien qu'il va être nécessaire de faire beaucoup de modifications pour s'assurer que tout continue de fonctionner, et qu'aucune erreur ne sera introduite quand il y aura encore plus de modifications. Une façon de limiter ces problèmes est d'écrire des tests automatiques qui puissent être lancés d'une manière simple et fiable à chaque fois que vous faites une modification. Ce tutoriel montre comment automatiser des tests unitaires sur votre site web en utilisant le framework de tests de Django.

- +
- + @@ -34,7 +34,7 @@ translation_of: Learn/Server-side/Django/Testing

Vue d'ensemble

-

Le site Local Library a actuellement des pages pour afficher des listes de tous les livres et auteurs, des pages de détail pour les éléments de type Book et Author, une page pour renouveler des BookInstances, et des pages pour créer, mettre à jour et effacer des éléments de type Author (et également des enregistrements de type Book, si vous avez relevé le défi dans le tutoriel sur les formulaires). Même avec ce site relativement petit, naviguer manuellement vers chaque page et vérifier superficiellement que tout fonctionne comme prévu peut prendre plusieurs minutes. Quand nous allons faire des modifications et agrandir le site, le temps requis pour vérifier manuellement que tout fonctionne "proprement" va grandir. Si nous continuons comme cela, nous allons sûrement passer beaucoup de temps à tester notre code, et peu à l'améliorer.

+

Le site Local Library a actuellement des pages pour afficher des listes de tous les livres et auteurs, des pages de détail pour les éléments de type Book et Author, une page pour renouveler des BookInstances, et des pages pour créer, mettre à jour et effacer des éléments de type Author (et également des enregistrements de type Book, si vous avez relevé le défi dans le tutoriel sur les formulaires). Même avec ce site relativement petit, naviguer manuellement vers chaque page et vérifier superficiellement que tout fonctionne comme prévu peut prendre plusieurs minutes. Quand nous allons faire des modifications et agrandir le site, le temps requis pour vérifier manuellement que tout fonctionne "proprement" va grandir. Si nous continuons comme cela, nous allons sûrement passer beaucoup de temps à tester notre code, et peu à l'améliorer.

Les tests automatiques peuvent vraiment nous aider à régler ce problème. Les avantages évidents sont qu'ils peuvent être lancés bien rapidement que des tests manuels, peuvent réaliser des tests à un niveau bien plus bas de détail, et tester exactement les mêmes fonctionnalités à chaque fois (des testeurs humains sont loin d'être aussi fiables !). Parce qu'ils sont rapides, les tests automatisés peuvent être exécutés plus régulièrement, et si un test échoue, ils pointent exactement vers la partie du code qui n'a pas fonctionné comme prévu.

@@ -56,14 +56,14 @@ translation_of: Learn/Server-side/Django/Testing
-

Note : Les autres genres habituels de tests comprennent : la boîte noire, la boîte blanche, les tests manuels, automatiques, de canari (canary), de fumée (smoke), de conformité (conformance), d'approbation (acceptance), fonctionnels, système, performance, chargement et stress. Consultez pour plus d'information sur chacun d'eux.

+

Note : Les autres genres habituels de tests comprennent : la boîte noire, la boîte blanche, les tests manuels, automatiques, de canari (canary), de fumée (smoke), de conformité (conformance), d'approbation (acceptance), fonctionnels, système, performance, chargement et stress. Consultez pour plus d'information sur chacun d'eux.

Que fournit Django pour tester ?

Tester un site web est une tâche complexe, car c'est une opération qui comporte plusieurs couches de logique : depuis la couche HTTP, la gestion des requêtes, les modèles d'interrogation de bases de données, jusqu'à la validation des formulaires, leur traitement et le rendu des templates.

-

Django fournit un framework de test avec une petite hiérarchie de classes construites sur la librairie standard de Python unittest. Malgré son nom, ce framework de test est utilisable pour les tests unitaires aussi bien que pour les tests d'intégration. Le framework Django ajoute les méthodes et les outils d'une API pour aider à tester un site web et les comportements spécifiques à Django. Ces méthodes vous permettent de simuler des requêtes, d'insérer des données de test et d'inspecter la sortie de votre application. Django fournit aussi une API (LiveServerTestCase) et des outils pour utiliser d'autres frameworks de test. Par exemple vous pouvez intégrer le célèbre framework Selenium pour simuler l'interaction entre un utilisateur et un vrai navigateur.

+

Django fournit un framework de test avec une petite hiérarchie de classes construites sur la librairie standard de Python unittest. Malgré son nom, ce framework de test est utilisable pour les tests unitaires aussi bien que pour les tests d'intégration. Le framework Django ajoute les méthodes et les outils d'une API pour aider à tester un site web et les comportements spécifiques à Django. Ces méthodes vous permettent de simuler des requêtes, d'insérer des données de test et d'inspecter la sortie de votre application. Django fournit aussi une API (LiveServerTestCase) et des outils pour utiliser d'autres frameworks de test. Par exemple vous pouvez intégrer le célèbre framework Selenium pour simuler l'interaction entre un utilisateur et un vrai navigateur.

Pour écrire un test, vous partez de l'une des classes de test de base fournies par Django (ou par unittest) (SimpleTestCase, TransactionTestCase, TestCase, LiveServerTestCase), et ensuite vous écrivez des méthodes séparées pour vérifier que telle fonctionnalité se comporte comme prévu (les tests utilisent des méthodes "assert" pour vérifier qu'une expression retourne True ou False, ou que deux valeurs sont égales, etc.). Quant vous commencez à lancer un test, le framework exécute les méthodes de test écrites dans vos classes dérivées. Les méthodes de test sont lancées de manière indépendante, avec en commun un réglage initial (setUp) et/ou un comportement de fin (tearDown) définis dans la classe, comme indiqué ci-dessous.

@@ -109,7 +109,7 @@ translation_of: Learn/Server-side/Django/Testing     def __str__(self):         return '%s, %s' % (self.last_name, self.first_name) -

De même, vous pouvez tester que les méthodes personnalisées get_absolute_url() et __str__() se comportent comme prévu, car elles appartiennent à votre logique code/métier. Dans le cas de get_absolute_url(), vous pouvez supposer que la méthode Django reverse() a été implémentée correctement, aussi ce que vous allez tester, c'est que la vue associée a été effectivement définie.

+

De même, vous pouvez tester que les méthodes personnalisées get_absolute_url() et __str__() se comportent comme prévu, car elles appartiennent à votre logique code/métier. Dans le cas de get_absolute_url(), vous pouvez supposer que la méthode Django reverse() a été implémentée correctement, aussi ce que vous allez tester, c'est que la vue associée a été effectivement définie.

Note : Les lecteurs attentifs auront noté que nous pourrions aussi vouloir limiter les dates de naissance et de décès à des valeurs sensibles, et vérifier que le décès intervient après la naissance. En Django, cette contrainte est ajoutée à vos classes de formulaires (bien que vous puissiez définir des validateurs pour les champs du modèle et des validateurs de modèles, ceux-ci ne sont utilisés qu'au niveau du formulaire s'ils sont appelés par la méthode clean() du modèle. Cela requière un ModelForm ou bien la méthode clean() du modèle a besoin d'être appelée explicitement.)

@@ -134,7 +134,7 @@ translation_of: Learn/Server-side/Django/Testing

Créez une structure de fichier comme montré ci-dessus, dans votre projet LocalLibrary. Le ficheir __init__.py doit être vide (il dit simplement à Python que ce répertoire est un package). Vous pouvez créer les trois fichiers de test en copiant et renommant le fichier de test du squelette /catalog/tests.py.

-

Note : le fichier de test du squelette /catalog/tests.py a été créé automatiquement quand nous avons construit le squelette du site web Django. Il est parfaitement "légal" de mettre tous vos tests dedans, mais si vous testez correctement, vous allez rapidement vous retrouver avec un fichier de test énorme et impossible à gérer.

+

Note : le fichier de test du squelette /catalog/tests.py a été créé automatiquement quand nous avons construit le squelette du site web Django. Il est parfaitement "légal" de mettre tous vos tests dedans, mais si vous testez correctement, vous allez rapidement vous retrouver avec un fichier de test énorme et impossible à gérer.

Supprimez le fichier de squelette, car nous n'en aurons plus besoin.

@@ -182,7 +182,7 @@ translation_of: Learn/Server-side/Django/Testing
-

Les classes de test ont aussi une méthode tearDown(), que nous n'avons pas utilisée. Cette méthode n'est pas particulièrement utile pour les tests avec bases de données, dans la mesure où la classe de base TestCase prend soin pour vous de supprimer la base de données utilisées pour les tests.

+

Note : Les classes de test ont aussi une méthode tearDown(), que nous n'avons pas utilisée. Cette méthode n'est pas particulièrement utile pour les tests avec bases de données, dans la mesure où la classe de base TestCase prend soin pour vous de supprimer la base de données utilisées pour les tests.

En dessous de ces méthodes, nous avons un certain nombre de méthodes de test, qui utilisent des fonctions Assert, pour tester si certaines conditions sont vraies, fausses ou égales (AssertTrue, AssertFalse, AssertEqual). Si la condition ne renvoie pas le résultat escompté, le test plante et renvoie une erreur à votre console.

@@ -190,7 +190,7 @@ translation_of: Learn/Server-side/Django/Testing

Les méthodes AssertTrue, AssertFalse et AssertEqual sont des assertions standard fournies par unittest. Il y a d'autres assertions standard dans le framework, et aussi des assertions spécifiques à Django, pour tester si une vue redirige (assertRedirects), pour tester si tel template a été utilisé (assertTemplateUsed), etc.

-

Normallement vous ne devriez pas inclure de fonctions print() dans vos tests, comme montré ci-dessus. Nous avons fait cela uniquement pour que vous puissiez voir dans la console (dans la section suivante) l'ordre dans lequel les fonctions de setup sont appelées.

+

Note : Normallement vous ne devriez pas inclure de fonctions print() dans vos tests, comme montré ci-dessus. Nous avons fait cela uniquement pour que vous puissiez voir dans la console (dans la section suivante) l'ordre dans lequel les fonctions de setup sont appelées.

Comment lancer les tests

@@ -202,7 +202,7 @@ translation_of: Learn/Server-side/Django/Testing

Cette commande va lancer la recherche de tous les fichiers ayant la forme test*.py sous le répertoire courant, et lancer tous les tests définis, en utilisant les classes de base appropriées (ici nous avons un certain nombre de fichiers de test, mais pour le moment seul /catalog/tests/test_models.py contient des tests). Par défaut, chaque test ne fera de rapport qu'en cas d'échec, avec ensuite un résumé du test.

-

Si vous obtenez des erreurs telles que : ValueError: Missing staticfiles manifest entry ..., cela peut être dû au fait que le test ne lance pas collectstatic par défaut, et que votre application utilise une classe de storage qui le requiert (voyez manifest_strict pour plus d'information). Il y a plusieurs façons de remédier à ce problème - la plus facile est de lancer tout simplement collectstatic avant de lancer les tests :

+

Note : Si vous obtenez des erreurs telles que : ValueError: Missing staticfiles manifest entry ..., cela peut être dû au fait que le test ne lance pas collectstatic par défaut, et que votre application utilise une classe de storage qui le requiert (voyez manifest_strict pour plus d'information). Il y a plusieurs façons de remédier à ce problème - la plus facile est de lancer tout simplement collectstatic avant de lancer les tests :

python3 manage.py collectstatic
@@ -238,7 +238,7 @@ Destroying test database for alias 'default'...

Ici nous voyons que nous avons eu un échec pour un test, et nous pouvons voir exactement quelle fonction a planté et pourquoi (cet échec était prévu, car False n'est pas True !).

-

Truc: La chose la plus importante à apprendre de la sortie de test ci-dessus est qu'il est bien mieux d'utiliser des noms descriptifs/informatifs pour vos objets et méthodes.

+

Note : La chose la plus importante à apprendre de la sortie de test ci-dessus est qu'il est bien mieux d'utiliser des noms descriptifs/informatifs pour vos objets et méthodes.

Le texte en gras ci-dessus n'apparaîtra pas normalement dans la sortie de test (elle est générée par les fonctions print() dans nos tests). Cela montre comment la méthode setUpTestData() est appelée une fois pour l'ensemble de classe, tandis que setUp() est appelée avant chaque méthode.

@@ -275,7 +275,7 @@ python3 manage.py test catalog.tests.test_models.YourTestClass.test_one_plus_one

Maintenant que nous savons comment lancer nos tests et quel genre de choses nous avons besoin de tester, regardons quelques exemples pratiques.

-

Note : Nous n'allons pas écrire tous les tests possibles, mais ce qui suit devrait vous donner une idée sur le fonctionnement des tests, et ce que vous pouvez faire ensuite.

+

Note : Nous n'allons pas écrire tous les tests possibles, mais ce qui suit devrait vous donner une idée sur le fonctionnement des tests, et ce que vous pouvez faire ensuite.

Modèles

@@ -386,7 +386,7 @@ AssertionError: 'Died' != 'died'

C'est vraiment un bug mineur, mais il met en lumière comment écrire des test peut vérifier de plus près les hypothèses que vous pourriez avoir supposées vraies.

-

Note : Changez en "died" le label pour le champ date_of_death (/catalog/models.py) et relancez les tests.

+

Note : Changez en "died" le label pour le champ date_of_death (/catalog/models.py) et relancez les tests.

La configuration pour tester les autres modèles est semblable pour tous, aussi nous n'allons pas discuter chacune plus longuement. Sentez-vous libre de créer vos propres tests pour nos autres modèles.

@@ -848,7 +848,7 @@ class RenewBookInstancesViewTest(TestCase):
-

Si vous utilisez la class de formulaire RenewBookModelForm(forms.ModelForm) à la place de la classe RenewBookForm(forms.Form), le nom du champ est 'due_back' et non 'renewal_date'.

+

Attention : Si vous utilisez la class de formulaire RenewBookModelForm(forms.ModelForm) à la place de la classe RenewBookForm(forms.Form), le nom du champ est 'due_back' et non 'renewal_date'.

Le test suivant (ajoutez-le à la classe également) vérifie que la vue redirige vers une liste de tous les livres empruntés si le renouvellement réussit. Ce qui diffère ici est que, pour la première fois, nous montrons comment vous pouvez POSTer des données en utilisant le client. Les données postées forment le second argument de la fonction post, et elles sont spécifiées comme un dictionnaire de clés/valeurs.

@@ -861,7 +861,7 @@ class RenewBookInstancesViewTest(TestCase):
-

La vue all-borrowed a été ajoutée comme défi, et votre code peut, à la place, rediriger vers la page d'accueil '/'. Si c'est le cas, modifiez les deux dernières lignes du code de test pour qu'elles ressemblent au code ci-dessous. L'expression follow=True dans la requête s'assure que la requête retourne l'URL de la destination finale (donc vérifie /catalog/ plutôt que /).

+

Attention : La vue all-borrowed a été ajoutée comme défi, et votre code peut, à la place, rediriger vers la page d'accueil '/'. Si c'est le cas, modifiez les deux dernières lignes du code de test pour qu'elles ressemblent au code ci-dessous. L'expression follow=True dans la requête s'assure que la requête retourne l'URL de la destination finale (donc vérifie /catalog/ plutôt que /).

 response = self.client.post(reverse('renew-book-librarian', kwargs={'pk':self.test_bookinstance1.pk,}), {'renewal_date':valid_date_in_future}, follow=True )
  self.assertRedirects(response, '/catalog/')
@@ -898,7 +898,7 @@ class RenewBookInstancesViewTest(TestCase):
  • Coverage: Cet outil Python fait un rapport sur la proportion de votre code réellement exécutée par vos tests. C'est particulièrement intéressant quand vous commencez, et que vous cherchez à vous représenter exactement ce que vous devez tester.
    • -
  • Selenium est un framework pour automatiser les tests dans un vrai navigateur. Il vous permet de simuler un utilisateur réel en interaction avec le site, et fournit un excellent framework pour les tests système de votre site (l'étape qui suit les tests d'intégration).
    • +
  • Selenium est un framework pour automatiser les tests dans un vrai navigateur. Il vous permet de simuler un utilisateur réel en interaction avec le site, et fournit un excellent framework pour les tests système de votre site (l'étape qui suit les tests d'intégration).

Défi

@@ -938,19 +938,19 @@ class RenewBookInstancesViewTest(TestCase):

Dans ce module

-- cgit v1.2.3-54-g00ecf
Prérequis:Avoir terminé tous les tutoriels précédents, y compris Django Tutorial Part 9: Working with forms.Avoir terminé tous les tutoriels précédents, y compris Django Tutorial Part 9: Working with forms.
Objectif: