[PYTHON] [Django] Formulaire de connexion standard de test [TDD]

Comment tester LoginForm lorsque j'essaye de le tester avec Django ... Comment le tester avec un pseudonyme ...? J'ai fait un test en réfléchissant, je vais donc laisser une note en mémoire.

environnement

version
python 3.7.4
Django 2.2.5

Le test utilise le test standard de Django (s'appelle-t-il ʻunit test`?).

Que tester

Pensez d'abord à ce qu'il faut tester. En conclusion, j'ai décidé de tester les éléments suivants:

Ce sont les trois ci-dessus. Je vais énumérer ci-dessous ce à quoi je pensais, mais je mentionnerai également pourquoi je ne l'ai pas testé.

Ce que vous voulez tester Pourquoi ne pas tester
Validation du formulaire(Caractères inutilisables)vérifier Tout ce dont vous avez besoin est lorsque vous vous inscrivez en tant qu'utilisateur(Si vous ne pouvez pas vous inscrire, vous ne pouvez pas vous connecter)
Vérifiez si vous avez pu vous connecter Ne semble-t-il pas que vous ne pouvez pas tester votre connexion parce que vous avez un jeton CSRF?
client.Vérification de la connexion à l'aide de la connexion Je n'utilise pas de formulaire donc je ne pense pas que ce soit nécessaire

C'est tout. Quand je l'ai relu, j'ai l'impression que LoginForm et LoginView sont en désordre. Cependant, étant donné que LoginView n'utilise que LoginForm, je pense qu'il suffit de tester les formulaires.

Code des vues et des formulaires

Les formulaires à tester cette fois et le code Views utilisé.

Views.py


from django.contrib.auth.views import LoginView
from ..forms import LoginForm

class Login(LoginView):
    form_class = LoginForm
    template_name = 'account_management/login.html'
    def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs) #Appelez d'abord la méthode héritée
        context["username"] = self.request.user.username
        return context

Views.py


from django.contrib.auth.forms import AuthenticationForm

class LoginForm(AuthenticationForm):
    """Formulaire de connexion"""

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        for field in self.fields.values():
            field.widget.attrs['class'] = 'form-control'
            field.widget.attrs['placeholder'] = field.label  #Mettre l'étiquette de champ dans l'espace réservé

Écrire le code de test

Maintenant, écrivons le code de test pour les formulaires ci-dessus. test sera décrit dans «tests.py». (Si vous avez modifié le répertoire, veuillez le lire comme il convient.) Les noms de classe et les noms de méthode doivent commencer par «test». Le code est ci-dessous.

Views.py


from django.test import TestCase
from django.contrib.auth.models import User
from ..forms import LoginForm

class Test_LoginForm(TestCase):

    def setUp(self):
        User.objects.create_user(username='test_account', email='[email protected]', password='test_pass') 
   
    def test_LoginForm_name_error(self):
        form_data = {
            'username': 'error',
            'password': 'test_pass'
        }
        form = LoginForm(data=form_data)
        self.assertFalse(form.is_valid(), 'Il n'y a pas eu d'erreur correcte avec le nom d'utilisateur.')
    
    def test_LoginForm_pass_error(self):
        form_data = {
            'username': 'test_account',
            'password': 'error'
        }
        form = LoginForm(data=form_data)
        self.assertFalse(form.is_valid(), 'Le mot de passe n'a pas donné une erreur correcte.')

    def test_LoginForm_true(self):
        form_data = {
            'username': 'test_account',
            'password': 'test_pass'
        }
        form = LoginForm(data=form_data)
        self.assertTrue(form.is_valid(), 'Le formulaire ne fonctionnait pas correctement.')

Jetons un coup d'œil à l'intérieur de la classe. setUp sera exécuté juste avant que la méthode de la classe ne soit exécutée. Les tests de Django recréent la base de données pour chaque test, vous devez donc définir l'utilisateur à chaque fois. Donc, cette fois, je définis l'utilisateur dans setUp.

Vient ensuite chaque méthode de test. Il n'y a pas de grande différence entre les trois, je vais donc les expliquer ensemble. Dans LoginForm, vous pouvez entrer votre nom d'utilisateur et votre mot de passe, et s'ils sont corrects, vous pouvez vous connecter. Dans form_data, ce qui est passé à quel champ est décrit dans le type de dictionnaire. Ensuite, transmettez les données à LoginForm.

Si la valeur passée est correcte avec la paire nom d'utilisateur et mot de passe enregistrés (car c'est une connexion cette fois), form.is_valid () retournera True. Sinon, il renvoie «False».

Cette fois, les deux méthodes ci-dessus sont censées renvoyer une erreur, c'est-à-dire qu'elles attendent False. self.assertFalse (form.is_valid (), 'Le mot de passe n'a pas donné une erreur correcte.') Est écrit. Si vous attendez «True», ce sera «Assert True». Les arguments pour ʻassertFalse sont la valeur à évalueret leaffichage en cas d'erreur`.

Quand tu fais ça,

$ python manage.py test account_management/tests -k
Using existing test database for alias 'default'...
System check identified no issues (0 silenced).
...
----------------------------------------------------------------------
Ran 4 tests in 3.196s

OK
Preserving test database for alias 'default'...

Vous pouvez voir que le test a réussi comme ça. La commande -k est une option qui ne supprime pas la base de données créée dans le test, mais utilise également la suivante. Je voulais vérifier la base de données après l'exécution, alors je l'ai attachée et exécutée.

Résumé

Je ne sais pas si ça correspond, mais j'ai pu faire un test pour le moment. Pour une raison quelconque, il m'a fallu un jour pour y arriver. J'espère que cela vous permettra de créer des tests ultérieurs en douceur ...

Recommended Posts

[Django] Formulaire de connexion standard de test [TDD]
Test Django
[Django] Comment tester le formulaire [TDD]
Tester la sortie standard avec Pytest
[Django] Je voulais tester lors du POST d'un fichier volumineux [TDD]
Développement piloté par les tests avec Django Partie 4
Développement piloté par les tests avec Django Partie 6
Développement piloté par les tests avec Django Partie 2
[Test Driven Development (TDD)] Chapitre 21 Résumé
Développement piloté par les tests avec Django Partie 1
Développement piloté par les tests avec Django Partie 5