Développement piloté par les tests avec Django Partie 2

Ceci est une note d'apprentissage pour comprendre le développement piloté par les tests (TDD) dans Django.

Les références sont [** Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript (English Edition) 2nd Edition **](https://www.amazon.co.jp/dp/B074HXXXLS Nous allons procéder à l'apprentissage basé sur / ref = dp-kindle-redirect? _ Encoding = UTF8 & btkr = 1).

Dans ce livre, nous menons des tests fonctionnels en utilisant la série Django 1.1 et FireFox, mais cette fois nous effectuerons des tests fonctionnels sur la série Djagno 3 et Google Chrome. J'ai également apporté quelques modifications personnelles (comme changer le nom du projet en Config), mais il n'y a pas de changements majeurs.

⇒⇒ Cliquez ici pour la Partie 1

Part1. The Basics of TDD and Django

Chapter2 Extending Our Functional Test Usinng the unittest Module

Dans Chapitre 1, vous pouvez écrire le premier test fonctionnel à partir de la construction de l'environnement de Django et vérifier si la page Default de Django fonctionne à travers le test fonctionnel. C'est fait. Cette fois, je voudrais appliquer cela à la page d'accueil lors de la création d'une application ToDo.

Les tests avec le pilote Web de Chrome et Selenium sont appelés ** tests fonctionnels **, car ils vous permettent de voir ** comment votre application fonctionne ** du point de vue de l'utilisateur. Il retrace la * user story * lorsqu'un utilisateur utilise une application et peut être dit pour déterminer comment l'utilisateur utilise l'application et comment l'application y répond.

Functional Test == Acceptance Test == End-To-End Test

** Test-Driven Development with Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript (English Edition) 2nd Edition ** Dans / B074HXXXLS / ref = dp-kindle-redirect? _ Encoding = UTF8 & btkr = 1), tester la fonction (* fonction *) d'une application s'appelle * tests fonctionnels *, donc dans cet article, cela s'appelle un test fonctionnel. Je vais. Ceci est également appelé * tests d'acceptation *, * tests de bout en bout (tests E2E, tests d'intégration) *. Le but de ce test est de voir comment l'ensemble de l'application fonctionne de l'extérieur.

Maintenant, écrivons-le sous forme de commentaire dans le test fonctionnel tout en supposant la véritable user story.

# django-tdd/functional_tests.py

from selenium import webdriver

browser = webdriver.Chrome()

#Nobita est une nouveauté-J'ai entendu dire qu'il y avait une application do et j'ai accédé à la page d'accueil.
browser.get('http://localhost:8000')

#Nobita a le titre et l'en-tête de la page-J'ai confirmé que cela suggère qu'il s'agit d'une application do.
assert 'To-Do' in browser.title

#Nobita est de-Invité à remplir l'élément à faire


#Nobita a écrit dans la zone de texte "Acheter Dorayaki"(Son meilleur ami aime dorayaki)


#Lorsque Nobita appuie sur Entrée, la page est actualisée
# "1:Acheter Dorayaki"Est de-Il s'avère qu'il a été ajouté en tant qu'élément à la liste de tâches


#La zone de texte vous permet de continuer à remplir les éléments, donc
#Rempli "Facturation de l'argent pour Dorayaki"(Il est serré quand il s'agit d'argent)


#La page a été actualisée à nouveau et j'ai pu voir que de nouveaux éléments ont été ajoutés


#Nobita est-ce pour-Je me demandais si l'application do enregistrait correctement mes éléments,
#Lorsque j'ai vérifié l'URL, j'ai trouvé que l'URL semble être une URL spécifique pour Nobita


#Lorsque Nobita a tenté d'accéder à une URL spécifique qu'il avait confirmée une fois,


#J'étais heureux de m'endormir car les articles étaient rangés.


browser.quit()

Changement de l'affirmation sur le titre de "Django" à "To-Do". On s'attend à ce que le test fonctionnel échoue tel quel. Faisons donc un test fonctionnel.

#Démarrer le serveur local
$ python manage.py runserver

#Lancer une autre ligne de commande
#Exécuter un test fonctionnel
$ python functional_tests.py

Traceback (most recent call last):
  File "functional_tests.py", line 11, in <module>
    assert 'To-Do' in browser.title
AssertionError

Le test a échoué comme prévu. Par conséquent, nous savons que nous devons procéder au développement pour que ce test puisse réussir.

Utiliser le module unittest

Dans le test fonctionnel, nous venons d'exécuter

--AssertioError n'est pas gentil (j'espère que vous savez quel était vraiment le titre du navigateur)

Le navigateur lancé par Selenium n'est pas effacé et reste

Il y avait de la contrariété. Ceux-ci peuvent être résolus à l'aide du module unittest, qui est un module Python standard.

Réécrivons le test fonctionnel comme suit.

# django-tdd/functional_tests.py

from selenium import webdriver
import unittest


class NewVisitorTest(unittest.TestCase):

    def setUp(self):
        self.browser = webdriver.Chrome()

    def tearDown(self):
        self.browser.quit()

    def test_can_start_a_list_and_retrieve_it_later(self):
        #Nobita est une nouveauté-J'ai entendu dire qu'il y avait une application do et j'ai accédé à la page d'accueil.
        self.browser.get('http://localhost:8000')

        #Nobita a le titre et l'en-tête de la page-J'ai confirmé que cela suggère qu'il s'agit d'une application do.
        self.assertIn('To-Do', self.browser.title)
        self.fail('Finish the test!')

        #Nobita est de-Invité à remplir l'élément à faire

        #Nobita a écrit dans la zone de texte "Acheter Dorayaki"(Son meilleur ami aime dorayaki)

        #Lorsque Nobita appuie sur Entrée, la page est actualisée
        # "1:Acheter Dorayaki"Est de-Il s'avère qu'il a été ajouté en tant qu'élément à la liste de tâches

        #La zone de texte vous permet de continuer à remplir les éléments, donc
        #Rempli "Facturation de l'argent pour Dorayaki"(Il est à court d'argent)

        #La page a été actualisée à nouveau et j'ai pu voir que de nouveaux éléments ont été ajoutés

        #Nobita est-ce pour-Je me demandais si l'application do enregistrait correctement mes éléments,
        #Lorsque j'ai vérifié l'URL, j'ai trouvé que l'URL semble être une URL spécifique pour Nobita

        #Lorsque Nobita a tenté d'accéder à une URL spécifique qu'il avait confirmée une fois,

        #J'étais heureux de m'endormir car les articles étaient rangés.


if __name__ == '__main__':
    unittest.main(warnings='ignore')

Les tests fonctionnels peuvent être écrits en héritant d'unittest.TestCase. Trions les points cette fois.

La fonction de test que vous souhaitez exécuter commence par * test_ *, et le testeur exécute automatiquement le test.
- setUp * et * tearDown * sont des fonctions spéciales qui sont exécutées avant et après l'exécution du test.
- tearDown * est également exécuté avec une erreur de test. --Self.fail () échouera au test et crachera une erreur. --Unittest.main () exécute le test et exécute automatiquement le cas de test et ses méthodes.
Si vous ajoutez l'option warnings = 'ignore', vous pouvez ignorer les avertissements excessifs de ressources, etc.

Lançons-le.

$ python functional_tests.py
======================================================================
FAIL: test_can_start_a_list_and_retrieve_it_later (__main__.NewVisitorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "functional_tests.py", line 20, in test_can_start_a_list_and_retrieve_it_later
    self.assertIn('To-Do', self.browser.title)
AssertionError: 'To-Do' not found in 'Django:Framework Web pour les perfectionnistes qui ne ratent jamais une échéance'

----------------------------------------------------------------------
Ran 1 test in 7.956s

FAILED (failures=1)

Le module unittest facilite la compréhension du contenu de * AssertionError *.

Si vous remplacez * self.assertIn ('To-Do', self.brower.title) * par * self.assertIn ('Django', self.brower.title) *, vous devriez pouvoir effacer le test. Vérifions ça.

# django-tdd/functional_tests.py
# ~~réduction~~
    def test_can_start_a_list_and_retrieve_it_later(self):
        #Nobita est une nouveauté-J'ai entendu dire qu'il y avait une application do et j'ai accédé à la page d'accueil.
        self.browser.get('http://localhost:8000')

        #Nobita a le titre et l'en-tête de la page-J'ai confirmé que cela suggère qu'il s'agit d'une application do.
        self.assertIn('Django', self.browser.title)  #Changement
        self.fail('Finish the test!')
# ~~réduction~~

$ python functinal_tests.py
======================================================================
FAIL: test_can_start_a_list_and_retrieve_it_later (__main__.NewVisitorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "functional_tests.py", line 21, in test_can_start_a_list_and_retrieve_it_later
    self.fail('Finish the test!')
AssertionError: Finish the test!

----------------------------------------------------------------------
Ran 1 test in 6.081s

FAILED (failures=1)

À la suite de l'exécution, le test devrait réussir, mais le test est ÉCHEC. Quand j'ai vérifié * AssertionError *, le message défini par * self.fail ('Terminer le test') * était reflété. C'est parce que * self.fail ('message') * a une fonction pour toujours cracher le message d'erreur défini, même s'il n'y a pas d'erreur. Ici, il est défini comme un rappel pour vous informer que le test est terminé.

Alors maintenant, commentons * self.fail ('Terminez le test!') * Et exécutez-le.

# django-tdd/functional_tests.py
# ~~réduction~~
    def test_can_start_a_list_and_retrieve_it_later(self):
        #Nobita est une nouveauté-J'ai entendu dire qu'il y avait une application do et j'ai accédé à la page d'accueil.
        self.browser.get('http://localhost:8000')

        #Nobita a le titre et l'en-tête de la page-J'ai confirmé que cela suggère qu'il s'agit d'une application do.
        self.assertIn('Django', self.browser.title)
        # self.fail('Finish the test!')  #Commenter
# ~~réduction~~

$ python functinal_tests.py

.
----------------------------------------------------------------------
Ran 1 test in 7.698s

OK

Il a été confirmé qu'il n'y avait pas d'erreur et que le test était réussi. La sortie finale du test fonctionnel devrait ressembler à ceci. Annulons les modifications de * functional_tests.py *.

# django-tdd/functional_tests.py
# ~~réduction~~
    def test_can_start_a_list_and_retrieve_it_later(self):
        #Nobita est une nouveauté-J'ai entendu dire qu'il y avait une application do et j'ai accédé à la page d'accueil.
        self.browser.get('http://localhost:8000')

        #Nobita a le titre et l'en-tête de la page-J'ai confirmé que cela suggère qu'il s'agit d'une application do.
        self.assertIn('To-do', self.browser.title)
        self.fail('Finish the test!')
# ~~réduction~~

Commit

En ajoutant des user stories avec des commentaires, j'ai pu créer et exécuter des tests fonctionnels pour les applications à faire. Engageons-nous ici. J'ai pu confirmer le fichier modifié en faisant ** git status **.

Vous pouvez vérifier la différence avec le dernier commit en faisant ** git diff **. Lorsque vous faites cela, vous pouvez voir que functional_tests.py a considérablement changé.

Engageons-nous.

$ git add .
$ git commit -m "First FT specced out in comments, and now users unittest"

Résumé du chapitre 2

Nous avons pu faire passer les tests fonctionnels du niveau de confirmation du lancement d'un projet Django à un autre basé sur une user story utilisant une application To-Do. Nous avons également constaté que l'utilisation d'unittest pouvait mieux utiliser les messages d'erreur.

[PYTHON] Développement piloté par les tests avec Django Partie 2

Développement piloté par les tests avec Django Partie 2

Utiliser le module unittest

Résumé du chapitre 2