One place for hosting & domains

      Django

      Comment ajouter les tests unitaires à votre projet Django


      L’auteur a choisi le Open Internet/Free Speech Fund pour recevoir un don dans le cadre du programme Write for Donations.

      Introduction

      Il est presque impossible de construire des sites web qui fonctionnent parfaitement du premier coup sans erreurs. C’est pourquoi vous devez tester votre application web pour trouver ces erreurs et y remédier de manière proactive. Afin d’améliorer l’efficacité des tests, il est courant de décomposer les tests en unités qui testent des fonctionnalités spécifiques de l’application web. Cette pratique est appelée les tests unitaires.   Il est plus facile de détecter les erreurs, car les tests se concentrent sur de petites parties (unités) de votre projet indépendamment des autres parties.

      Tester un site web peut être une tâche complexe à entreprendre car il est constitué de plusieurs couches de logique comme le traitement des requêtes HTTP, la validation des formulaires et les modèles de rendu. Cependant, Django fournit un ensemble d’outils qui permettent de tester votre application web en toute transparence.   Dans Django, la façon préférée d’écrire des tests est d’utiliser le module Python unittest, bien qu’il soit possible d’utiliser d’autres cadres de test. 

      Dans ce tutoriel, vous allez mettre en place une suite de tests dans votre projet Django et écrire des tests unitaires pour les modèles et les vues de votre application. Vous effectuerez ces tests, analyserez leurs résultats et apprendrez comment trouver les causes des échecs.

      Conditions préalables

      Avant de commencer ce tutoriel, vous aurez besoin des éléments suivants :

      Étape 1 – Ajouter une séquence de tests à votre demande Django

      Une séquence de tests dans Django est une collection de tous les scénarios de test de toutes les applications de votre projet. Pour permettre à l’utilitaire de test de Django de découvrir les scénarios de test que vous avez, vous écrivez les scénarios de test dans des scripts dont le nom commence par test.   Au cours de cette étape, vous allez créer la structure des répertoires et des fichiers de votre séquence de tests, et y créer un scénario de test vide.

      Si vous avez suivi la série de tutoriels Django Development, vous aurez une application Django appelée blogsite.

      Créons un dossier pour contenir tous nos scripts de test. Tout d’abord, activez l’environnement virtuel :

      • cd ~/my_blog_app
      • . env/bin/activate

      Ensuite, naviguez vers le répertoire appblogsite, le dossier qui contient les fichiers models.py et views.py, puis créez un nouveau dossier appelé tests :

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      Ensuite, vous transformerez ce dossier en un paquet Python, ajoutez donc un fichier __init__.py :

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      Vous allez maintenant ajouter un fichier pour tester vos modèles et un autre pour tester vos vues :

      • touch test_models.py
      • touch test_views.py

      Enfin, vous allez créer un scénario de test vide dans test_models.py. Vous devrez importer la classe Django TestCase et en faire une super classe de votre propre classe de test case. Plus tard, vous ajouterez des méthodes à ce scénario de test pour tester la logique de vos modèles. Ouvrez le fichier test_models.py :

      Ajoutez maintenant le code suivant au fichier :

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      Vous avez maintenant ajouté avec succès une séquence de tests à l’appli blogsite. Ensuite, vous remplirez les détails du modèle de cas test vide que vous avez créé ici.

      Étape 2 – Tester votre code Python

      Dans cette étape, vous allez tester la logique du code écrit dans le fichier models.py. En particulier, vous testerez la méthode de sauvegarde du modèle Post afin de vous assurer qu’il crée la bonne portion du titre d’un message lorsqu’il est appelé. 

      Commençons par regarder le code que vous avez déjà dans votre fichier models.py pour la méthode de sauvegarde du modèle Post :

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      Vous verrez ce qui suit :

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      On peut voir qu’il vérifie si le message sur le point d’être sauvegardé a une valeur de slug, et si ce n’est pas le cas, il appelle slugify pour lui créer une valeur de slug. C’est le type de logique que vous pourriez vouloir tester pour vous assurer que les slugs sont effectivement créés lors de la sauvegarde d’un message.

      Fermez le dossier.

      Pour le tester, retournez à test_models.py :

      Mettez-le ensuite à jour en ajoutant les parties surlignées :

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      Cette nouvelle méthode test_post_has_slug crée un nouvel article avec le titre « My first post », puis donne à l’article un auteur et l’enregistre. Ensuite, à l’aide de la méthode assertEqual du module Python unittest, il vérifie si le slug du message est correct. La méthode assertEqual vérifie si les deux arguments qui lui sont transmis sont égaux tels que déterminés par l’opérateur « == » et signale une erreur s’ils ne le sont pas.

      Sauvegarder et quitter test_models.py.

      Voici un exemple de ce qui peut être testé. Plus vous ajoutez de logique à votre projet, plus il y a de choses à tester. Si vous ajoutez plus de logique à la méthode de sauvegarde ou créez de nouvelles méthodes pour le modèle Post, vous voudriez ajouter plus de tests ici. Vous pouvez les ajouter à la méthode test_post_has_slug ou créer de nouvelles méthodes de test, mais leurs noms doivent commencer par test.

      Vous avez créé avec succès un cas test pour le modèle Post où vous avez affirmé que les slugs sont correctement créés après la sauvegarde. Dans l’étape suivante, vous rédigerez un scénario de test pour tester les vues.

      Étape 3 – Utiliser le client test de Django

      Dans cette étape, vous allez écrire un scénario de test qui teste une vue en utilisant le client de test Django. Le test client est une classe Python qui agit comme un navigateur web factice, vous permettant de tester vos vues et d’interagir avec votre application Django de la même manière qu’un utilisateur le ferait. Vous pouvez accéder au client test en vous référant à self.client dans vos méthodes de test. Par exemple, créons un cas test dans test_views.py Tout d’abord, ouvrez le fichier test_views.py :

      Ajoutez ensuite ce qui suit :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      Le ViewsTestCase contient une méthode test_index_loads_properly qui utilise le client de test Django pour visiter la page d’index du site (http://your_server_ip:8000, où your_server_ip est l’adresse IP du serveur que vous utilisez). Ensuite, la méthode de test vérifie si la réponse a un code de statut de 200, ce qui signifie que la page a répondu sans aucune erreur. Vous pouvez donc être sûr que lorsque l’utilisateur se rendra sur le site, il répondra lui aussi sans erreur.

      Outre le code de statut, vous pouvez lire d’autres propriétés de la réponse du client de test que vous pouvez tester dans la page des réponses de test de la documentation de Django.

      Au cours de cette étape, vous avez créé un scénario de test pour vérifier que la vue rendant la page d’index fonctionne sans erreur. Il y a maintenant deux scénarios de test dans votre séquence de tests. Au cours de l’étape suivante, vous les exécuterez pour voir leurs résultats.

      Étape 4 – Effectuer vos tests

      Maintenant que vous avez terminé la construction d’une séquence de tests pour le projet, il est temps d’exécuter ces tests et de voir leurs résultats. Pour effectuer les tests, naviguez dans le dossier blog (contenant le fichier manage.py de l’application) :

      Puis, exécutez-les :

      Vous verrez un résultat similaire à ce qui suit dans votre terminal :

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      Dans cette sortie, il y a deux points .., dont chacun représente un cas de test réussi. Vous allez maintenant modifier test_views.py pour déclencher un test d’échec. Ouvrez le fichier avec :

      Ensuite, changez le code en surbrillance pour :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Ici, vous avez changé le code de statut de 200 à 404. Maintenant, refaites le test à partir de votre répertoire avec manage.py :

      Vous verrez la sortie suivante :

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      Vous voyez qu’il y a un message d’échec descriptif qui vous indique le script, le cas de test et la méthode qui a échoué. Il vous indique également la cause de l’échec, le code de statut n’étant pas égal à 404 dans ce cas, avec le message AssertionError: 200 !  404. L’AssertionError est ici soulevée à la ligne de code surlignée dans le fichier test_views.py :

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Il vous indique que l’affirmation est fausse, c’est-à-dire que le code de statut de réponse (200) n’est pas ce à quoi on s’attendait (404). Précédant le message d’échec, vous pouvez voir que les deux points .. sont maintenant passés à . F, qui vous indique que le premier cas test a réussi alors que le second ne l’a pas fait.

      Conclusion

      Dans ce tutoriel, vous avez créé une suite de tests dans votre projet Django, ajouté des scénarios de test au modèle de test et à la logique de visualisation, appris comment exécuter des tests et analysé les résultats des tests. Dans un deuxième temps, vous pouvez créer de nouveaux scripts de test pour le code Python qui n’est pas dansmodels.py et views.py.

      Voici quelques articles qui peuvent s’avérer utiles pour créer et tester des sites web avec Django :

      Vous pouvez également consulter notre page thématique sur Django pour d’autres tutoriels et projets.



      Source link

      Comment installer Django et mettre en place un environnement de développement sur Ubuntu 20.04


      Introduction

      Django est un framework web libre et open-source écrit en Python dont les principes de base sont l’extensibilité, la réutilisation et le développement rapide. Il est également connu pour sa cohérence au niveau du framework et son couplage lâche, qui permet aux différents composants d’être indépendants les uns des autres.

      Dans ce tutoriel, nous allons mettre en place un environnement Django à des fins de développement sur un serveur Ubuntu 20.04. Pour un site web en direct, vous aurez des considérations supplémentaires, notamment la connexion à une base de données, la mise en place d’un nom de domaine et l’ajout de couches de sécurité. Nous avons une variété de tutoriels sur Django qui peuvent vous aider à construire sous notre label Django.

      Conditions préalables

      Pour pouvoir suivre ce tutoriel, vous aurez besoin de :

      Étape 1 — Installation de Django

      Il existe plusieurs façons d’installer Django, le gestionnaire de packages Python pip dans un environnement virtuel.

      Dans le répertoire d’origine du serveur, nous allons créer le répertoire qui contiendra notre application Django. Exécutez la commande suivante pour créer un répertoire appelé django-apps, ou un autre nom de votre choix.  Naviguez ensuite vers le répertoire.

      • mkdir django-apps
      • cd django-apps

      Dans le répertoire django-apps, créez votre environnement virtuel. Nous l’appellerons le générique env, mais vous devez utiliser un nom qui est significatif pour vous et votre projet.

      Maintenant, activez l’environnement virtuel avec la commande suivante :

      Vous saurez qu’il est activé dès que le préfixe sera changé en (env), ce qui ressemblera à ce qui suit, selon le répertoire dans lequel vous vous trouvez :

      Dans l’environnement, installez le package Django en utilisant pip. L’installation de Django nous permet de créer et d’exécuter des applications Django.

      Une fois installé, vérifiez votre installation Django en effectuant un contrôle de version :

      Ceci, ou quelque chose similaire, sera la sortie qui en résulte :

      Output

      3.0.6

      Une fois Django installé sur votre serveur, nous pouvons passer à la création d’un projet test pour nous assurer que tout fonctionne correctement. Nous allons créer un squelette d’application web.

      Étape 2 – Ajuster les paramètres du pare-feu

      Si vous avez suivi notre tutoriel de configuration initiale du serveur ou que vous avez un pare-feu sur votre serveur, nous devrons ouvrir le port que nous utiliserons dans le pare-feu de notre serveur. Pour le pare-feu UFW, vous pouvez ouvrir le port avec la commande suivante :

      Si vous utilisez les pare-feu DigitalOcean, vous pouvez sélectionner HTTP dans les règles d’entrée. Vous pouvez en savoir plus sur les pare-feu DigitalOcean et sur la création de règles pour ceux-ci en modifiant les règles d’entrée.

      Étape 3 — Démarrage du projet

      Nous pouvons maintenant générer une application en utilisant django-admin, un utilitaire en ligne de commande pour les tâches d’administration en Python. Ensuite, nous pouvons utiliser la commande startproject pour créer la structure du répertoire projet pour notre site web test.

      Dans le répertoire django-apps, exécutez la commande suivante :

      • django-admin startproject testsite

      Remarque : L’exécution de la commande django-admin startproject <projectname> donnera au répertoire du projet et au package du projet le nom <projectname> et créera le projet dans le répertoire dans lequel la commande a été exécutée. Si le paramètre facultatif <destination> est fourni, Django utilisera le répertoire de destination fourni comme répertoire du projet, et créera le fichier manage.py et le package du projet à l’intérieur de celui-ci.

      Nous pouvons maintenant voir quels fichiers de projet viennent d’être créés. Naviguez vers le répertoire testsite puis listez le contenu de ce répertoire pour voir quels fichiers ont été créés :

      Output

      manage.py testsite

      Vous remarquerez une sortie qui montre ce répertoire contient un fichier nommé manage.py et un dossier nommé testsite. Le fichier manage.py est similaire à django-admin et place le package du projet sur sys.path. Cela permet également de faire pointer la variable d’environnement DJANGO_SETTINGS_MODULE sur le fichier settings.py de votre projet.

      Vous pouvez visualiser le script manage.py dans votre terminal en exécutant la commande less comme ceci :

      Lorsque vous avez terminé la lecture du script, appuyez sur q, pour quitter la visualisation du fichier.

      Naviguez maintenant dans le répertoire testsite pour visualiser les autres fichiers qui ont été créés :

      Exécutez ensuite la commande suivante pour lister le contenu du répertoire :

      Vous verrez quatre fichiers :

      Output

      __init__.py asgi.py settings.py urls.py wsgi.py

      Examinons la nature de chacun de ces fichiers :

      • __init__.py agit comme point d’entrée pour votre projet Python.
      • asgi.py contient la configuration pour le déploiement optionnel à l’Asynchronous Server Gateway Interface ou ASGI, qui fournit un standard pour les applications qui sont soit synchrones soit asynchrones, et est considéré comme un successeur du WSGI (voir ci-dessous).
      • settings.py décrit la configuration de votre installation Django et permet à Django de connaître les paramètres disponibles.
      • urls.py contient une liste d’urlpatterns, qui dirige et fait correspondre les URL à leurs vues.
      • wsgi.py contient la configuration de la Web Server Gateway Interface ou WSGI, qui fournit un standard pour les applications Python synchrones.

      Remarque : Bien que les fichiers par défaut soient générés, vous avez encore la possibilité de modifier les fichiers asgi.py ou wsgi.py à tout moment pour répondre à vos besoins de déploiement.

      Étape 4 — Configuration de Django

      Nous pouvons maintenant démarrer le serveur et visualiser le site web sur un hôte et un port désignés en exécutant la commande runserver.

      Nous devrons ajouter l’adresse ip de votre serveur à la liste des ALLOWED_HOSTS dans le fichier settings.py situé dans ~/test_django_app/testsite/testsite/.

      Comme indiqué dans la documentations de Django, la variable ALLOWED_HOSTS contient « une liste des chaînes de caractères représentant les noms d’hôtes/domaines que ce site Django peut servir. Il s’agit d’une mesure de sécurité pour prévenir les attaques d’en-tête HTTP Host, qui sont possibles même dans de nombreuses configurations de serveurs web apparemment sûres. »

      Vous pouvez utiliser votre éditeur de texte préféré pour ajouter votre adresse IP. Par exemple, si vous utilisez nano, exécutez la commande suivante :

      • nano ~/django-apps/testsite/testsite/settings.py

      Une fois la commande exécutée, vous devrez vous rendre dans la section “Allowed Host du document et ajouter l’adresse IP de votre serveur entre des crochets, dans des guillemets simples ou doubles.

      settings.py

      """
      Django settings for testsite project.
      
      Generated by 'django-admin startproject' using Django 2.0.
      ...
      """
      ...
      # SECURITY WARNING: don't run with debug turned on in production!
      DEBUG = True
      
      # Edit the line below with your server IP address
      ALLOWED_HOSTS = ['your-server-ip']
      ...
      

      Vous pouvez enregistrer la modification et quitter nano en appuyant sur la touche CTRL + x, puis sur la touche y. Ensuite, nous allons accéder à notre application web via un navigateur.

      Enfin, créons un utilisateur administratif afin de pouvoir utiliser l’interface d’admin de Djano. Pour le faire, utilisons la commande createsuperuser.

      • python manage.py createsuperuser

      Vous serez invité à saisir le nom d’utilisateur, l’adresse électronique et le mot de passe de votre utilisateur.

      Étape 5 — Accès à l’application web Django

      Une fois notre configuration terminée, assurez-vous de revenir au répertoire où se trouve manage.py :

      • cd ~/django-apps/testsite/

      Maintenant, exécutez la commande suivante en remplaçant le texte your-server-ip par l’IP de votre serveur :

      • python manage.py runserver 0.0.0.0:8000

      Enfin, vous pouvez naviguer vers le lien ci-dessous pour voir à quoi ressemble votre squelette de site web, en remplaçant à nouveau le texte en surbrillance par l’IP réelle de votre serveur :

      http://your-server-ip:8000/
      

      Une fois la page chargée, vous verrez ce qui suit :

      Page par défaut de Django

      Cela confirme que Django a été correctement installé et notre projet test fonctionne correctement.

      Pour accéder à l’interface d’administration, ajoutez /admin/ à la fin de votre URL :

      http://your_server_ip:8000/admin/
      

      Cela vous amènera à un écran de connexion :

      Connexion à l'interface d'administration de Django

      Si vous entrez le nom d’utilisateur et le mot de passe admin que vous venez de créer, vous aurez accès à la section admin principale du site :

      Page d'administration de Django

      Pour plus d’informations sur l’utilisation de l’interface d’administration de Django, veuillez consulter la section Comment activer et connecter l’interface d’administration de Django.

      Lorsque vous avez fini de tester votre application, vous pouvez appuyer sur CTRL + C pour arrêter la commande runserver​​​. Cela vous renverra à votre environnement de programmation.

      Lorsque vous êtes prêt à quitter votre environnement Python, vous pouvez exécuter la commande deactivate :

      La désactivation de votre environnement de programmation vous ramènera à l’invite de commande du terminal.

      Conclusion

      Dans ce tutoriel, vous avez réussi à installer Django et à mettre en place un environnement de développement pour commencer à travailler sur votre application Django.

      Vous disposez maintenant des bases nécessaires pour commencer à construire des applications web Django.



      Source link

      Cómo agregar prueba de unidades a su proyecto de Django


      El autor seleccionó a Open Internet/Free Speech Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Es casi imposible crear sitios web que desde el principio funcionen a la perfección y no tengan errores. Por ese motivo, debe probar su aplicación web para encontrar esos errores y trabajar en ellos de forma proactiva. Para mejorar la eficiencia de las pruebas, es común desglosarlas en unidades que prueben funcionalidades específicas de la aplicación web. Esta práctica se denomina prueba de unidades. Hace que sea más fácil detectar errores, dado que las pruebas se centran en pequeñas partes (unidades) de su proyecto independientemente de otras.

      Probar un sitio web puede ser una tarea compleja, ya que consta de varias capas de lógica, como la gestión de solicitudes HTTP, la validación de formularios y la representación de plantillas. Sin embargo, Django ofrece un conjunto de herramientas que le permite probar su aplicación web sin problemas. Aunque es posible utilizar otros marcos de pruebas, la opción preferida para escribir pruebas en Django es usar el módulo unittest de Python.

      A través de este tutorial, configurará un conjunto de pruebas en su proyecto de Django y escribirá pruebas de unidades para los modelos y vistas de su aplicación. Ejecutará estas pruebas, analizará sus resultados y aprenderá a encontrar las causas de errores en las pruebas que fallan.

      Requisitos previos

      Antes de iniciar este tutorial, necesitará lo siguiente:

      Paso 1: Agregar un conjunto de pruebas a su aplicación en Django

      Un conjunto de pruebas en Django es una colección de todos los casos de prueba en todas las aplicaciones de su proyecto. Para lograr que la utilidad de prueba de Django descubra los casos de prueba que tiene, se escriben los casos de prueba en secuencias de comandos cuyos nombres comiencen con test. En este paso, creará la estructura del directorio y los archivos para su conjunto de pruebas, y creará un caso de prueba vacío dentro de él.

      Si siguió la serie de tutoriales Desarrollo en Django, tendrá una aplicación de Django denominada blogsite.

      Crearemos una carpeta para contener todos nuestros scripts de prueba. Primero, active el entorno virtual:

      • cd ~/my_blog_app
      • . env/bin/activate

      Luego, diríjase al directorio de la aplicación blogsite, la carpeta que contiene los archivos models.py y views.py, y luego cree una carpeta nueva llamada tests:

      • cd ~/my_blog_app/blog/blogsite
      • mkdir tests

      A continuación, convertirá esta carpeta en un paquete Python; agregue un archivo __init__.py:

      • cd ~/my_blog_app/blog/blogsite/tests
      • touch __init__.py

      Ahora, agregue un archivo para probar sus modelos y otro para probar sus vistas:

      • touch test_models.py
      • touch test_views.py

      Por último, creará un caso de prueba vacío en test_models.py. Deberá importar la clase TestCase de Django y hacer que sea una súper clase de su propia clase de caso de prueba. Más adelante, añadirá métodos a este caso de prueba para probar la lógica en sus modelos. Abra el archivo test_models.py​​​1​​​:

      Luego, añada el siguiente código al archivo:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      
      class ModelsTestCase(TestCase):
          pass
      

      De esta manera, habrá añadido correctamente un conjunto de pruebas a la aplicación blogsite. Luego, completará los detalles del caso de prueba de modelo vacío que creó aquí.

      Paso 2: Probar su código Python

      En este paso, probará la lógica del código escrito en el archivo models.py. En particular, probará el método save del modelo Post para asegurarse de que cree el slug correcto del título de una entrada cuando se invoque.

      En este caso, comenzaremos observando el código que ya tiene en su archivo models.py para ver el método save del modelo Post:

      • cd ~/my_blog_app/blog/blogsite
      • nano models.py

      Observará lo siguiente:

      ~/my_blog_app/blog/blogsite/models.py

      class Post(models.Model):
          ...
          def save(self, *args, **kwargs):
              if not self.slug:
                  self.slug = slugify(self.title)
              super(Post, self).save(*args, **kwargs)
          ...
      

      Podemos ver que verifica si la entrada que está a punto de guardar tiene un valor slug, y, si no, invoca a slugify a fin de crear un valor slug para la misma. Este es el tipo de lógica que tal vez quiera probar para asegurarse de que los slugs se creen en realidad cuando se guarde una entrada.

      Cierre el archivo.

      Para probar esto, regrese a test_models.py:

      Luego, actualícelo para que se vea como a continuación y agregue las porciones resaltadas:

      ~/my_blog_app/blog/blogsite/tests/test_models.py

      from django.test import TestCase
      from django.template.defaultfilters import slugify
      from blogsite.models import Post
      
      
      class ModelsTestCase(TestCase):
          def test_post_has_slug(self):
              """Posts are given slugs correctly when saving"""
              post = Post.objects.create(title="My first post")
      
              post.author = "John Doe"
              post.save()
              self.assertEqual(post.slug, slugify(post.title))
      

      Este nuevo método test_post_has_slug crea una nueva entrada con el título "My first post" y, luego, atribuye a esta un autor y la guarda. Después de esto, usando el método assertEqual del módulo unittest de Python, se comprueba si el slug de la entrada es correcto. El método assertEqual verifica si los dos argumentos que se le pasan son iguales, como lo determina el operador "==", y genera un error si no lo son.

      Guarde y cierre test_models.py.

      Este es un ejemplo de lo que se puede probar. Cuanta más lógica añada a su proyecto, habrá más por probar. Si añade más lógica al método save o crea nuevos métodos para el modelo Post, querrá añadir más pruebas aquí. Usted puede añadirlas al método test_post_has_slug o crear nuevos métodos de prueba, pero sus nombres deben comenzar con test.

      Creó con éxito un caso de prueba para el modelo Post, en el que validó que los slugs se crean correctamente después del guardado. En el siguiente paso, escribirá un caso de prueba para probar las vistas.

      Paso 3: Usar el cliente de prueba de Django

      En este paso, escribirá un caso de prueba que probará una vista utilizando el cliente de prueba de Django. El cliente de prueba es una clase de Python que funciona como navegador web ficticio, le permite probar sus vistas e interactuar con su aplicación Django como un usuario lo haría. Puede acceder al cliente de prueba haciendo referencia a self.client en sus métodos de prueba. Por ejemplo, crearemos un caso de prueba en test_views.py. Primero, abra el archivo test_views.py:

      Luego, agregue lo siguiente:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 200)
      

      El ViewsTestCase contiene un método test_index_loads_properly que utiliza el cliente de prueba de Django para visitar la página principal del sitio web (http://your_server_ip:8000, donde your_server_ip es la dirección IP del servidor que utiliza). Luego, el método de prueba comprueba si la respuesta tiene un código de estado 200, lo cual significa que la página respondió sin errores. Como resultado, puede estar seguro de que cuando el usuario visite la página también responderá sin errores.

      Además del código de estado, puede leer sobre otras propiedades de la respuesta del cliente de prueba que puede probar en la página de documentación de respuestas de prueba de Django.

      En este paso, creó un caso de prueba para probar la vista que genera la página principal y verificar que funcione sin errores. Ahora, hay dos casos de prueba en su conjunto de pruebas. En el siguiente paso, los ejecutará para ver sus resultados.

      Paso 4: Ejecutar sus pruebas

      Ahora que terminó de crear un conjunto de pruebas para el proyecto, es el momento de ejecutar estas pruebas y ver sus resultados. Para ejecutar las pruebas, diríjase a la carpeta blog (que contiene el archivo manage.py de la aplicación):

      Luego, ejecútelas con lo siguiente:

      Verá un resultado similar al siguiente en su terminal:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .. ---------------------------------------------------------------------- Ran 2 tests in 0.007s OK Destroying test database for alias 'default'...

      En este resultado, hay dos puntos .., cada uno de los cuales representa un caso de prueba aprobado. Ahora, modificará test_views.py para activar una prueba que falle. Abra el archivo con lo siguiente:

      Luego, cambie el código resaltado para ver lo siguiente:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Aquí, cambió el código de estado de 200 a 404. Ahora, ejecute la prueba de nuevo desde su directorio con manage.py:

      Verá el siguiente resultado:

      Output

      Creating test database for alias 'default'... System check identified no issues (0 silenced). .F ====================================================================== FAIL: test_index_loads_properly (blogsite.tests.test_views.ViewsTestCase) The index page loads properly ---------------------------------------------------------------------- Traceback (most recent call last): File "~/my_blog_app/blog/blogsite/tests/test_views.py", line 8, in test_index_loads_properly self.assertEqual(response.status_code, 404) AssertionError: 200 != 404 ---------------------------------------------------------------------- Ran 2 tests in 0.007s FAILED (failures=1) Destroying test database for alias 'default'...

      Verá aparecer un mensaje de error descriptivo en el que se indicará la secuencia de comandos, el caso de prueba y el método que falló. También se mostrará la causa de la falla, con un código de estado que no es igual al 404 en este caso, con el mensaje AssertionError: 200 ! = 404. El AssertionError aquí se genera en la línea de código resaltada en el archivo test_views.py:

      ~/my_blog_app/blog/blogsite/tests/test_views.py

      from django.test import TestCase
      
      
      class ViewsTestCase(TestCase):
          def test_index_loads_properly(self):
              """The index page loads properly"""
              response = self.client.get('your_server_ip:8000')
              self.assertEqual(response.status_code, 404)
      

      Le indica que la afirmación es falsa, es decir, el código de estado de respuesta (200) no es lo que se esperaba (404). Precediendo el mensaje de error, puede ver que los dos puntos .. pasaron a ser . F, lo cual indica que el primer caso de prueba se aprobó mientras que el segundo no.

      Conclusión

      A través de este tutorial, creó un conjunto de pruebas en su proyecto de Django, añadió casos de prueba para probar el modelo y la lógica de visualización, aprendió a ejecutar pruebas y analizó el resultado de una prueba. Como siguiente paso, puede crear nuevas secuencias de comandos para código Python que no estén en models.py y views.py.

      A continuación, consulte algunos artículos que pueden ser útiles al crear y probar sitios web con Django:

      También puede consultar nuestra página de temas de Django para ver tutoriales y proyectos adicionales.



      Source link