La classe RequestFactory partage la même API que le client de test. Cependant, au lieu de se comporter comme un navigateur, RequestFactory offre une manière de générer une instance de requête pouvant être utilisée comme premier paramètre de n’importe quelle vue. Cela permet de tester une fonction de vue de la même façon que vous testeriez toute autre fonction, comme une boîte noire, avec des données connues en entrée et en testant un résultat spécifique.
L’API de RequestFactory est un tout petit peu plus restreinte que celle du client de test :
Elle ne donne accès qu’aux méthodes HTTP get(), post(), put(), delete(), head(), options() et trace().
Toutes ces méthodes acceptent les mêmes paramètres, à l’exception de follow. Comme il ne s’agit que d’une fabrique produisant des requêtes, le traitement de la réponse est de votre responsabilité.
Elle ne gère pas les intergiciels. Les attributs de session et d’authentification doivent être fournis par le test lui-même, si nécessaire, pour que la vue fonctionne correctement.
L’exemple suivant est un test unitaire utilisant la fabrique de requêtes :
\nfrom django.contrib.auth.models import AnonymousUser, User\nfrom django.test import RequestFactory, TestCase\n\nfrom .views import MyView, my_view\n\n\nclass SimpleTest(TestCase):\n def setUp(self):\n # Every test needs access to the request factory.\n self.factory = RequestFactory()\n self.user = User.objects.create_user(\n username="jacob", email="jacob@…", password="top_secret"\n )\n\n def test_details(self):\n # Create an instance of a GET request.\n request = self.factory.get("/customer/details")\n\n # Recall that middleware are not supported. You can simulate a\n # logged-in user by setting request.user manually.\n request.user = self.user\n\n # Or you can simulate an anonymous user by setting request.user to\n # an AnonymousUser instance.\n request.user = AnonymousUser()\n\n # Test my_view() as if it were deployed at /customer/details\n response = my_view(request)\n # Use this syntax for class-based views.\n response = MyView.as_view()(request)\n self.assertEqual(response.status_code, 200)\nRequestFactory crée des requêtes de type WSGI. Si vous souhaitez créer des requêtes de type ASGI, ayant aussi une portée scope ASGI correcte, vous pouvez utiliser django.test.AsyncRequestFactory à la place.
L’API de cette classe est directement compatible avec RequestFactory, avec comme seule différence le renvoi d’instances ASGIRequest au lieu de WSGIRequest. Toutes ses méthodes restent des exécutables synchrones.
Les paramètres mot-clé arbitraires dans defaults sont ajoutés directement dans la portée ASGI.
Afin de tester les vues fondées sur des classes en dehors du cycle requête/réponse, vous devez vous assurer qu’elles sont configurées correctement en appelant setup() après leur instanciation.
Par exemple, en partant de la vue classe suivante :
\nviews.pyfrom django.views.generic import TemplateView\n\n\nclass HomeView(TemplateView):\n template_name = "myapp/home.html"\n\n def get_context_data(self, **kwargs):\n kwargs["environment"] = "Production"\n return super().get_context_data(**kwargs)\nVous pouvez directement tester la méthode get_context_data() en commençant par créer une instance de la vue, puis en passant une requête à setup() avant de procéder au test du code :
tests.pyfrom django.test import RequestFactory, TestCase\nfrom .views import HomeView\n\n\nclass HomePageTest(TestCase):\n def test_environment_set_in_context(self):\n request = RequestFactory().get("/")\n view = HomeView()\n view.setup(request)\n\n context = view.get_context_data()\n self.assertIn("environment", context)\nLe réglage ALLOWED_HOSTS est validé lors de l’exécution des tests. Cela permet au client de test de faire la différence entre les URL internes et externes.
Les projets qui gèrent plusieurs domaines par site ou adaptent leur comportement en fonction de l’hôte de la requête et qui utilisent des noms d’hôte particuliers dans les tests doivent inclure ces noms d’hôte dans ALLOWED_HOSTS.
La première option pour accomplir cela est d’ajouter les hôtes dans le fichier des réglages. Par exemple, la suite de tests de docs.djangoproject.com contient ceci :
\nfrom django.test import TestCase\n\n\nclass SearchFormTestCase(TestCase):\n def test_empty_get(self):\n response = self.client.get(\n "/en/dev/search/",\n headers={"host": "docs.djangoproject.dev:8000"},\n )\n self.assertEqual(response.status_code, 200)\net le fichier des réglages contient une liste des domaines pris en charge par le projet :
\nALLOWED_HOSTS = ["www.djangoproject.dev", "docs.djangoproject.dev", ...]\nUne autre option est d’ajouter les hôtes nécessaires dans ALLOWED_HOSTS en utilisant override_settings() ou modify_settings(). Cette option peut être préférable pour les applications autonomes qui ne peuvent pas fournir leur propre fichier de réglages ou pour les projets dont la liste des domaines n’est pas figée (par ex. des sous-domaines dans un service partagé). Par exemple, il serait possible d’écrire un test pour le domaine http://otherserver/ comme ceci :
from django.test import TestCase, override_settings\n\n\nclass MultiDomainTestCase(TestCase):\n @override_settings(ALLOWED_HOSTS=["otherserver"])\n def test_other_domain(self):\n response = self.client.get("http://otherserver/foo/bar/")\nLa désactivation du contrôle de ALLOWED_HOSTS (ALLOWED_HOSTS = ['*']) lors de l’exécution des tests empêche le client de test de produire un message d’erreur instructif si une redirection est appelée pour une URL externe.
Si vous testez une configuration avec plusieurs bases de données impliquant une réplication primaire/réplique (désignée comme maître/esclave par certaines bases de données), cette stratégie de création de bases de données de test pose un problème. Lorsque les bases de données de test sont créées, la réplication n’a pas lieu et par conséquent, les données créées sur la base primaire ne seront pas visibles sur les répliques.
\nPour contourner ce problème, Django permet de définir une base de données comme un miroir de test. Considérez cet exemple (simplifié) de configuration de bases de données :
\nDATABASES = {\n "default": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbprimary",\n # ... plus some other settings\n },\n "replica": {\n "ENGINE": "django.db.backends.mysql",\n "NAME": "myproject",\n "HOST": "dbreplica",\n "TEST": {\n "MIRROR": "default",\n },\n # ... plus some other settings\n },\n}\nDans cette configuration figurent deux serveurs de base de données : dbprimary, défini par l’alias de base de données default et dbreplica, défini par l’alias replica. Comme l’on peut s’y attendre, dbreplica a été configuré par l’administrateur de base de données comme réplique en lecture de dbprimary. En temps normal, toute écriture sur default apparaît aussi sur replica.
Si Django avait créé deux bases de données de test indépendantes, cela casserait d’éventuels tests s’attendant à de la réplication. Cependant, la base de données replica a été configurée comme miroir de test (via le réglage de test MIRROR), indiquant par là que lors des tests, replica doit être traité comme un miroir de default.
Au moment de la création de l’environnement de test, aucune base ne sera créée pour replica. Par contre, la connexion vers replica sera redirigée pour pointer vers default. Par conséquent, les écritures sur default apparaîtront aussi sur replica, mais parce qu’il s’agit en réalité de la même base de données, car aucune réplication de données ne sera mise en place entre les deux bases de données. Comme cela dépend des transactions, les tests doivent utiliser TransactionTestCase au lieu de TestCase.
Par défaut, Django part du principe que toutes les bases de données dépendent de la base de données default et va par conséquent toujours créer celle-ci en premier. Cependant, pour toute autre base de données de votre configuration de test, il n’y a aucune garantie sur l’ordre de création des bases de données.
Si votre configuration de base de données nécessite un ordre de création bien défini, vous pouvez indiquer les dépendances entre bases de données dans le réglage de test DEPENDENCIES. Considérez cet exemple (simplifié) de configuration de bases de données :
DATABASES = {\n "default": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "diamonds": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": [],\n },\n },\n "clubs": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds"],\n },\n },\n "spades": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "hearts"],\n },\n },\n "hearts": {\n # ... db settings\n "TEST": {\n "DEPENDENCIES": ["diamonds", "clubs"],\n },\n },\n}\nAvec cette configuration, la base de données diamonds sera créée en premier car c’est le seul alias de base de données sans dépendances. Les alias default et clubs seront ensuite créés (bien que l’ordre de création de ceux-ci ne soit pas défini), puis hearts et enfin, spades.
Si la définition de DEPENDENCIES comporte des dépendances circulaires, une exception ImproperlyConfigured sera générée.
TransactionTestCaseLien vers cette rubrique#Par défaut, available_apps vaut None. Après chaque test, Django appelle flush pour réinitialiser l’état de la base de données. Toutes les tables sont ainsi vidées et le signal post_migrate est émis, ce qui recrée un type de contenu et quatre permissions pour chaque modèle. Cette opération s’alourdit proportionnellement au nombre de modèles.
En définissant available_apps à une liste d’applications, Django se comporte comme si seuls les modèles de ces applications étaient disponibles. Le comportement de TransactionTestCase est modifié comme suit :
post_migrate est émis avant chaque test pour créer les types de contenu et les permissions de chaque modèle des applications disponibles, dans le cas où ils manqueraient.
Après chaque test, Django ne vide que les tables correspondants aux modèles des applications disponibles. Cependant, au niveau de la base de données, il est possible que les troncatures s’appliquent en cascade à des modèles liés dans des applications non disponibles. De plus, post_migrate n’est pas émis ; il sera émis par le prochain test TransactionTestCase, après que l’ensemble d’applications adéquat a été sélectionné.
Comme la base de données n’est pas complètement vidée, si un test crée des instances de modèles non inclus dans available_apps, ces instances vont rester et pourraient être la cause d’échecs de tests non liés. Restez prudent avec les tests employant des sessions ; le moteur de sessions par défaut les stocke dans la base de données.
Comme post_migrate n’est pas émis après la réinitialisation de la base de données, son état après un TransactionTestCase n’est pas le même qu’après un TestCase: les lignes créées par les récepteurs de post_migrate sont manquantes. Mais sachant l’ordre dans lequel les tests sont exécutés, ce n’est pas un problème, dans la mesure où soit tous les tests TransactionTestCase d’une suite de tests déclarent available_apps, soit aucun.
available_apps est obligatoire dans la propre suite de tests de Django.
En définissant reset_sequences = True d’une classe TransactionTestCase, vous vous assurez que les séquences sont toujours réinitialisées avant le lancement du test :
class TestsThatDependsOnPrimaryKeySequences(TransactionTestCase):\n reset_sequences = True\n\n def test_animal_pk(self):\n lion = Animal.objects.create(name="lion", sound="roar")\n # lion.pk is guaranteed to always be 1\n self.assertEqual(lion.pk, 1)\nÀ l’exception des cas où vous testez explicitement les numéros de séquence de clés primaires, il est recommandé de ne pas tester des valeurs de clés primaires figées.
\nL’utilisation de reset_sequences = True ralentit les tests, car la réinitialisation des clés primaires est une opération de base de données relativement coûteuse.
Si vous avez des classes de tests qui ne peuvent pas fonctionner en parallèle (par exemple si elles partagent une ressource commune), vous pouvez utiliser django.test.testcases.SerializeMixin pour les exécuter de manière séquentielle. Cette classe mixin utilise un fichier verrou lockfile du système de fichiers.
Par exemple, vous pouvez utiliser __file__ pour déterminer que toutes les classes de tests du même fichier héritant de SerializeMixin seront exécutées les unes à la suite des autres
import os\n\nfrom django.test import TestCase\nfrom django.test.testcases import SerializeMixin\n\n\nclass ImageTestCaseMixin(SerializeMixin):\n lockfile = __file__\n\n def setUp(self):\n self.filename = os.path.join(temp_storage_dir, "my_file.png")\n self.file = create_file(self.filename)\n\n\nclass RemoveImageTests(ImageTestCaseMixin, TestCase):\n def test_remove_image(self):\n os.remove(self.filename)\n self.assertFalse(os.path.exists(self.filename))\n\n\nclass ResizeImageTests(ImageTestCaseMixin, TestCase):\n def test_resize_image(self):\n resize_image(self.file, (48, 48))\n self.assertEqual(get_image_size(self.file), (48, 48))\nSi vous écrivez une application réutilisable, il peut être intéressant d’utiliser le lanceur de tests de Django pour lancer votre propre suite de tests et bénéficier ainsi de l’infrastructure de tests de Django.
\nUne pratique courante est de placer un répertoire tests en parallèle de votre code d’application, avec la structure suivante :
\nruntests.py\npolls/\n __init__.py\n models.py\n ...\ntests/\n __init__.py\n models.py\n test_settings.py\n tests.py\nExaminons ce qui se trouve dans certains de ces fichiers :
\nruntests.py#!/usr/bin/env python\nimport os\nimport sys\n\nimport django\nfrom django.conf import settings\nfrom django.test.utils import get_runner\n\nif __name__ == "__main__":\n os.environ["DJANGO_SETTINGS_MODULE"] = "tests.test_settings"\n django.setup()\n TestRunner = get_runner(settings)\n test_runner = TestRunner()\n failures = test_runner.run_tests(["tests"])\n sys.exit(bool(failures))\nIl s’agit ici du script invoqué pour lancer la suite de tests. Il met en place l’environnement Django, crée la base de données de tests et lance les tests.
\nPar souci de clarté, cet exemple ne contient que le strict minimum nécessaire à l’utilisation du lanceur de tests de Django. On peut cependant imaginer ajouter des options en ligne de commande pour le contrôle de la verbosité, pour passer des étiquettes de tests spécifiques à lancer, etc.
\ntests/test_settings.pySECRET_KEY = "fake-key"\nINSTALLED_APPS = [\n "tests",\n]\nCe fichier contient les réglages Django indispensables pour lancer les tests de votre application.
\nEncore une fois, il s’agit d’un exemple minimal ; les tests peuvent exiger des réglages supplémentaires pour fonctionner.
\nComme le paquet tests est inclus dans INSTALLED_APPS au moment de lancer les tests, il est possible de définir des modèles uniquement pour les tests dans le fichier models.py.
Il est clair que unittest n’est pas la seule infrastructure de test de Python. Même si Django ne fournit pas de prise en charge explicite d’autres systèmes de test, il offre une manière d’invoquer des tests construits pour un autre système comme s’il s’agissait de tests Django normaux.
Lorsque vous lancez ./manage.py test, Django consulte le réglage TEST_RUNNER pour déterminer ce qu’il doit faire. Par défaut, TEST_RUNNER contient 'django.test.runner.DiscoverRunner'. Cette classe définit le comportement de test par défaut de Django. Ce comportement implique :
Une préparation générale avant les tests.
La recherche de tests dans tout fichier au-dessous du répertoire actuel dont le nom correspond au motif test*.py.
La création des bases de données de test.
Le lancement de migrate pour installer les modèles et les données initiales dans les bases de données de test.
L’exécution des vérifications systèmes.
L’exécution des tests découverts.
La suppression des bases de données de test.
Une finalisation générale après les tests.
Si vous définissez votre propre classe de lanceur de tests et que vous indiquez cette classe dans TEST_RUNNER, Django se servira de votre lanceur de tests lors de chaque appel à ./manage.py test. De cette façon, il est possible d’utiliser n’importe quel système de test pouvant être lancé à partir de code Python ou de modifier le processus d’exécution des tests Django pour adapter les tests à d’éventuels besoins spécifiques.
Un lanceur de tests est une classe définissant une méthode run_tests(). Django fournit une classe DiscoverRunner définissant le comportement de test par défaut de Django. Cette classe définit le point d’entrée run_tests() ainsi qu’une sélection d’autres méthodes utilisées par run_tests() pour préparer, exécuter et clore la suite de tests.
DiscoverRunner recherche des tests dans tout fichier correspondant au motif pattern.
top_level peut être utilisé pour indiquer le répertoire contenant les modules Python de premier niveau. Django peut généralement le découvrir automatiquement, ce qui fait que cette option n’est pas absolument nécessaire. Lorsqu’elle est définie, elle devrait en principe correspondre au répertoire contenant le fichier manage.py.
verbosity détermine la quantité de notifications et d’informations de débogage qui s’afficheront sur la console ; 0 n’affiche rien, 1 correspond à l’affichage normal et 2 à l’affichage verbeux.
Si interactive vaut True, la suite de tests a le droit de poser des questions à l’utilisateur durant son exécution. Par exemple, elle pourrait demander la permission de supprimer une base de données de test existante. Si interactive vaut False, la suite de tests doit pouvoir s’exécuter sans aucune intervention manuelle de l’utilisateur.
Si failfast vaut True, la suite de tests s’arrête immédiatement après le premier échec de test.
Si keepdb vaut True, la suite de tests va utiliser la base de données existante ou en créer une si c’est nécessaire. Si la valeur est False, une nouvelle base de données est toujours créée, demandant à l’utilisateur de supprimer une éventuelle base existante de même nom.
Si reverse vaut True, les cas de tests sont exécutés dans l’ordre inverse. Cela peut être utile pour déboguer des tests qui ne sont pas isolés correctement et génèrent des effets de bord. Le groupement par classe de test est conservé lors de l’utilisation de cette option. Celle-ci peut être utilisée conjointement avec --shuffle pour inverser l’ordre d’une graine aléatoire particulière.
debug_mode indique la valeur que doit prendre le réglage DEBUG avant d’exécuter les tests.
parallel indique le nombre de processus. Si parallel est plus grand que 1, la suite de tests s’exécutera dans des processus en parallèle. S’il y a moins de classes de cas de test que de processus configurés, Django se charge de réduire le nombre de processus en conséquence. Chaque processus reçoit sa propre base de données. Cette option nécessite la présence du paquet tiers tblib pour afficher correctement les traces d’erreurs.
tags peut être utilisé pour définir un jeu d’étiquettes pour le filtrage des tests. Peut être combiné avec exclude_tags.
exclude_tags peut être utilisé pour définir un jeu d’étiquettes pour l’exclusion de tests. Peut être combiné avec tags.
Si debug_sql vaut True, les tests en échec affichent les requêtes SQL journalisées vers django.db.backends en plus de la pile d’appels. Si verbosity vaut 2, les requêtes de tous les tests sont affichées.
test_name_patterns peut être utilisé pour définir un ensemble de motifs pour filtrer les méthodes et classes de test par leur nom.
Si pdb vaut True, un débogueur (pdb ou ipdb) sera déclenché lors de chaque erreur ou échec de test.
Si buffer vaut True, la sortie des tests réussis sera omise.
Si enable_faulthandler vaut True, faulthandler sera activé.
Si timing vaut True, la mesure temporelle des tests sera affichée, y compris la mise en place de la base de données et le temps total d’exécution.
Si shuffle est un nombre entier, les cas de test seront mélangés aléatoirement avant leur exécution, en utilisant le nombre entier comme facteur aléatoire. Si shuffle vaut None, ce facteur sera généré aléatoirement. Dans les deux cas, le facteur sera journalisé et défini dans self.shuffle_seed avant de lancer les tests. Cette option peut être utilisée pour aider à détecter les tests qui ne sont pas proprement isolés. Le groupement par classe de test est conservé avec cette option.
logger peut être utilisé pour passer un objet Logger Python. Si indiqué, ce journaliseur sera utilisé pour journaliser les messages au lieu de les afficher dans la console. Cet objet journaliseur respectera son niveau de journalisation plutôt que le paramètre verbosity.
durations affiche une liste des N cas de tests les plus lents. En définissant cette option à 0, la durée de tous les tests sera affichée. Nécessite Python 3.12+.
Il est possible que de temps à autre, Django étende les capacités du lanceur de tests en ajoutant de nouveaux paramètres. La déclaration **kwargs permet cette extension. Si vous héritez de DiscoverRunner ou que vous écrivez votre propre lanceur de tests, vérifiez qu’il accepte **kwargs.
Votre lanceur de tests peut aussi définir des options supplémentaires en ligne de commande. Créez ou surchargez une méthode de classe add_arguments(cls, parser) et ajoutez des paramètres personnalisés en appelant parser.add_argument() dans cette méthode, afin que la commande test puisse exploiter ces paramètres.
La classe utilisée pour construire la suite de tests. Par défaut, il s’agit de unittest.TestSuite. Il est possible de surcharger cette valeur si vous souhaitez implémenter une logique différente pour collecter les tests.
Cette classe est celle du lanceur de tests de bas niveau utilisé pour exécuter les tests individuels et mettre en forme les résultats. Par défaut, il s’agit de unittest.TextTestRunner. Malgré la malencontreuse similitude des conventions de nommage, il ne s’agit pas du même type de classe que DiscoverRunner, qui prend en charge un plus grand spectre de responsabilités. Vous pouvez surcharger cet attribut pour modifier la façon dont les tests sont exécutés et leurs résultats affichés.
Il s’agit de la classe qui charge les tests, que ce soit à partir de classes TestCase, de modules ou d’autres façons, et qui les consolide en suites de tests que le lanceur pourra exécuter. Par défaut, c’est unittest.defaultTestLoader. Vous pouvez surcharger cet attribut si vos tests doivent être chargés de manière inhabituelle.
Lance la suite de tests.
\ntest_labels permet d’indiquer les tests à exécuter et accepte plusieurs formats (voir DiscoverRunner.build_suite() pour la liste des formats pris en charge).
Cette méthode doit renvoyer le nombre de tests ayant échoué.
\nSurchargez cette méthode de classe pour ajouter des paramètres personnalisés acceptés par la commande d’administration test. Voir argparse.ArgumentParser.add_argument() pour plus de détails au sujet de l’ajout de paramètres de ligne de commande.
Met en place l’environnement de test en appelant setup_test_environment() et en définissant DEBUG à self.debug_mode (False par défaut).
Construit une suite de tests correspondant aux noms de test indiqués.
\ntest_labels est une liste de chaînes décrivant les tests à exécuter. Un nom de test peut apparaître sous quatre formes :
chemin.vers.module_test.TestCase.methode_test – Lance une seule méthode de test dans une classe de cas de test.
chemin.vers.module_test.TestCase – Lance toutes les méthodes de test d’un cas de test.
chemin.vers.module – Recherche et lance tous les tests d’un paquet ou module Python donné.
chemin/vers/répertoire – Recherche et lance tous les tests dans la sous-arborescence du répertoire donné.
Si test_labels contient la valeur None, le lanceur de tests recherche des tests dans tous les fichiers au-dessous du répertoire actuel dont le nom correspond à son motif pattern (voir ci-dessus).
Renvoie une instance TestSuite prête à être exécutée.
Crée les bases de données de test en appelant setup_databases().
Lance les vérifications systèmes pour les bases databases de test.
Lance la suite de tests.
\nRenvoie le résultat produit par l’exécution de la suite de tests.
\nRenvoie les paramètres nommés pour l’instanciation de DiscoverRunner.test_runner.
Supprime les bases de données de test, rétablissant la situation d’avant-test en appelant teardown_databases().
Rétablit l’environnement à son état d’avant les tests.
\nCalcule et renvoie un code de retour basé sur une suite de tests et des résultats de ces tests.
\nQuand le paramètre logger est défini, journalise le message au niveau de journalisation donné (nombre entier), par ex. logging.DEBUG, logging.INFO ou logging.WARNING. Sinon, le message est affiché dans la console en respectant le paramètre verbosity en cours. Par exemple, aucun message ne sera affiché si verbosity vaut 0, les niveaux INFO et supérieurs seront affichés si verbosity vaut au moins 1, et les niveaux DEBUG seront affichés si verbosity vaut au moins 2. La valeur par défaut de level est logging.INFO.
django.test.utilsLien vers cette rubrique#Pour aider à la création de votre propre lanceur de tests, Django fournit un certain nombre de méthodes utilitaires dans le module django.test.utils.
Effectue la mise en place générale avant les tests, comme l’installation des adaptations du système de rendu des gabarits et la mise en place de la boîte de messagerie factice.
\nSi debug ne vaut pas None, le réglage DEBUG est mis à jour avec cette valeur.
Effectue la finalisation générale après les tests, comme la suppression des adaptations du système des gabarits et le rétablissement des services de messagerie par défaut.
\nCrée les bases de données de test.
\nRenvoie une structure de données fournissant suffisamment de détails pour annuler les changements effectués. Ces données sont ensuite transmises à la fonction teardown_databases() lors de la finalisation des tests.
Le paramètre aliases détermine pour quels alias de DATABASES les bases de données de test doivent être préparées. S’il n’est pas présent, sa valeur par défaut contient tous les alias de DATABASES.
Le paramètre serialized_aliases détermine le sous-ensemble des aliases de bases de données de test qui devraient avoir leur état sérialisé pour permettre l’utilisation de la fonctionnalité serialized_rollback. Si non défini, la valeur par défaut est aliases.
Supprime les bases de données de test, rétablissant la situation d’avant-test.
\nold_config est une structure de données définissant les modifications de la configuration des bases de données qui doivent être annulées. C’est la valeur de renvoi de la méthode setup_databases().
django.db.connection.creationLien vers cette rubrique#Le module de création du moteur de base de données propose également quelques utilitaires pouvant être utiles durant les tests.
\nCrée une nouvelle base de données de test et exécute migrate sur cette base.
verbosity a le même effet que dans run_tests().
autoclobber décrit le comportement adopté si une base de données de même nom que la base de données de test existe déjà :
Si autoclobber vaut False, l’utilisateur devra confirmer la suppression de la base de données existante. sys.exit est appelée si l’utilisateur refuse.
Si autoclobber vaut True, la base de données est supprimée sans rien demander à l’utilisateur.
serialize détermine si Django sérialise la base de données en une chaîne JSON en mémoire avant de lancer les tests (utilisé pour restaurer l’état de la base de données entre les tests s’il n’y a pas de transactions). Vous pouvez le définir à False pour accélérer nettement le temps de création si aucune de vos classes de test ne comporte serialized_rollback=True.
keepdb détermine si la session de test doit utiliser une base de données existante ou si elle doit en créer une nouvelle. Si True, une éventuelle base de données existante est utilisée, sinon une nouvelle base est créée. Si False, une nouvelle base de données sera créée dans tous les cas, en demandant à l’utilisateur s’il doit supprimer la base existante, s’il y en a une.
Renvoie le nom de la base de données de test qui a été créée.
\ncreate_test_db() présente un effet de bord : la valeur de NAME dans DATABASES est mise à jour pour correspondre au nom de la base de données de test.
Supprime la base de données dont le nom correspond à la valeur de NAME dans DATABASES et met à jour NAME avec la valeur contenue dans old_database_name.
Le paramètre verbosity a le même effet que pour DiscoverRunner.
Si le paramètre keepdb vaut True, la connexion à la base de données sera fermée, mais la base de données ne sera pas détruite.
Sérialise la base de données en une chaîne JSON en mémoire pouvant être utilisée pour restaurer l’état de la base de données entre les tests si le moteur ne gère par les transactions ou si votre suite de tests contient des tests avec la propriété serialized_rollback=True.
\nCette fonction ne devrait être appelée qu’après la création de toutes les bases de données de test car le processus de sérialisation pourrait aboutir à des requêtes appliquées sur des bases de données « non test », en fonction de votre configuration de routage.
\ncoverage.pyLien vers cette rubrique#La couverture de code représente la quantité de code source mis à l’épreuve par les tests. Elle montre quelles sont les parties de code que les tests éprouvent et les parties qui ne le sont pas. C’est un aspect important du test des applications, c’est pourquoi il est fortement recommandé de contrôler la couverture de vos tests.
\nDjango peut facilement s’intégrer à coverage.py, un outil de mesure de couverture du code de programmes Python. Premièrement, installez coverage. Puis, lancez la commande suivante à partir du répertoire de votre projet contenant manage.py:
coverage run --source='.' manage.py test myapp\nCela va lancer les tests et collecter les données de couverture des fichiers exécutés dans votre projet. Vous pouvez afficher un rapport de ces données en saisissant la commande suivante :
\ncoverage report\nNotez que du code Django a été exécuté lors de l’exécution des tests, mais il ne figure pas dans le rapport à cause de l’option source indiquée dans la commande précédente.
Pour davantage d’options comme les listings HTML annotés détaillant les lignes manquantes, consultez la documentation de coverage.py.
\n