Modifier la vue add_to_cart pour la tester

00:00:00 :Dans cette partie on va tester la logique de l'ajout au panier qui pour l'instant est un petit peu problématique puisqu'il se fait directement au niveau de la vue. Donc ce que je veux dire par
00:00:08 :là, si je reviens dans mon projet que je vais à l'intérieur du store dans views.py, quand on ajoute un élément dans le panier ça se fait directement dans cette vue add to cart. Vous
00:00:18 :voyez qu'on va récupérer le produit à partir du slog, ensuite on va récupérer le panier d'utilisateur, on va créer ou récupérer un produit existant et l'ajouter dans le panier ou modifier sa quantité s'il est déjà dans le panier. Donc toute cette logique elle se fait
00:00:31 :au niveau de la vue et c'est ça que j'aime bien également avec les tests unitaires puisque là encore c'est un très bon exemple qui vous montre que ça va vous permettre de réorganiser et de repenser votre code puisque là on voit bien que ça va être difficile de tester tout ça si on le
00:00:44 :laisse dans la vue. Nous ce qu'on veut c'est pouvoir le tester au niveau du modèle donc ce qu'on va pouvoir faire c'est prendre tout ça et en fait le basculer directement dans le modèle utilisateur. Généralement moi je préfère toujours avoir des modèles qui sont les plus
00:00:57 :complets possibles c'est une phrase qu'on entend généralement du côté anglophone d'avoir des modèles ce qu'on appelle fat donc gros entre guillemets et des vues qui sont les plus légères possibles puisque le fait d'avoir la logique à l'intérieur du modèle ça permet d'avoir une pensée, une façon de penser en fait qui est beaucoup plus orientée objet puisque là vous
00:01:16 :voyez qu'au niveau des vues on est avec des fonctions donc c'est un petit peu plus compliqué à chaque fois de tester ses comportements et donc on préfère avoir le moins de logique possible directement dans la vue et de pouvoir séparer tout ça dans des méthodes à l'intérieur de nos
00:01:29 :modèles. Donc ce que je vais faire moi c'est tout simplement en fait rajouter une méthode add to cart qu'on va mettre à l'intérieur du modèle de l'utilisateur donc la classe shopper donc je vais couper tout ça pour l'instant et on va aller dans projets, dans accounts donc dans les modèles ici, dans donc pas le custom user manager mais dans la classe ici shopper on va
00:01:49 :rajouter une méthode qu'on va appeler add to cart tout simplement et cette méthode on va devoir lui passer le slog du produit et je vais coller tout ce que j'avais coupé depuis la vue pour le remettre ici. Donc on va devoir régler les imports puisque on ne les a plus à l'intérieur de ce
00:02:02 :fichier donc je fais option entrée import django shortcut on va également importer le cart et le order ainsi que le produit donc là il s'agit du order à l'intérieur de store models et non pas le order de stripe, le produit on va l'importer également donc là encore c'est à l'intérieur de
00:02:20 :store.models et non pas stripe et l'utilisateur dans ce cas ci ce n'est plus user mais c'est tout simplement self puisque là on est au niveau de la classe donc on est avec notre instance. Et la
00:02:29 :dernière chose que je vais faire ici c'est tout simplement retourner le panier donc faire un return de cartes à la fin de cette méthode ici. Donc maintenant qu'on a déplacé tout ça ici on
00:02:39 :va pouvoir retourner dans notre vue et juste faire un user.addToCart et passer le slug ici au paramètre slug. Vous voyez par la même occasion que quand on a fait user là on n'avait pas
00:02:50 :l'autocomplétion là on l'a maintenant puisque j'ai rajouté cette ligne ici mais si je fais donc si je commente la ligne vous voyez que là on n'a pas l'autocomplétion. Donc pour retrouver
00:02:58 :l'autocomplétion ce qu'on peut faire c'est rajouter une annotation de type après la variable puisque dans ce cas ci request.user pour Django et Python c'est abstrait en fait ça pourrait être
00:03:07 :n'importe quel type de classe donc dans ce cas ci je vais dire que c'est en fait une instance de chopper et là si je refais user.je peux faire addToCart et je retrouve bien l'autocomplétion
00:03:16 :de la méthode qu'on vient d'ajouter. Donc on va spécifier ici slug égale à slug et ça va faire exactement la même chose et vous voyez qu'on retrouve donc une vue qui est maintenant beaucoup plus légère et toute la logique qui se retrouve au niveau de ma classe. Donc maintenant on va
00:03:30 :pouvoir tester cette méthode pour ça je vais créer des nouveaux fichiers et dossiers à l'intérieur cette fois ci de l'application accounts donc je vais supprimer le fichier de base test.py et à la place on va faire comme ce qu'on avait fait ici avec l'application store
00:03:43 :on va créer un nouveau dossier qu'on va appeler test avec un s à la fin on va mettre le fichier init à l'intérieur et on va créer un nouveau fichier donc un fichier python qui va s'appeler testmodels.py. A l'intérieur de ce fichier donc on va importer le testcase donc depuis
00:04:01 :django.test import testcase et on va également importer donc depuis accounts.models la classe shopper qu'on va utiliser. On va également importer depuis store.models le product puisqu'on va
00:04:13 :l'utiliser pour ajouter un produit à l'intérieur de notre panier. Donc qu'est ce qu'on va faire ici on va créer une nouvelle classe je vais l'appeler user test on va hériter de testcase et on va faire une méthode setup qui va nous permettre de créer un produit et un utilisateur
00:04:27 :et ensuite on va tester pour ajouter donc le produit à l'intérieur du panier utilisateur. Donc je vais faire product.object.create on va passer donc en nom on va remettre les sneakers de dogstring
00:04:39 :en price on va mettre 10 en stock on va mettre 10 donc je mets juste des valeurs ici pour avoir des valeurs par défaut on pourrait utiliser les valeurs par défaut qu'on a définis à l'intérieur de product puisqu'ici on a des valeurs par défaut mais dans mon cas je vais mettre quand même des
00:04:52 :valeurs ici qui vont être un petit peu différentes. On n'oublie pas la virgule entre chaque paramètre et la description de superbes sneakers. Donc là je suis pas obligé de mettre tous ces paramètres
00:05:02 :ici je pourrais juste laisser le nom ça n'a pas beaucoup d'importance. On va créer ensuite un utilisateur donc qui va être égal à shopper.object.create user et on va passer un email je
00:05:13 :vais mettre test.gmail.com et pour le password on va mettre aussi quelque chose de test comme ceci. Donc là l'utilisateur je le récupère dans self.user puisque je vais devoir utiliser en fait
00:05:23 :cet utilisateur dans la méthode de test qu'on va créer tout de suite et le produit je vais tout simplement me baser sur le slog puisque c'est le slog que l'on passe à add to cart ici donc ce n'est pas un objet que je passe mais directement le slog donc je vais pouvoir passer le slog de sneakers
00:05:37 :dogstring directement. Là encore il y a plein de façons de faire les choses c'est vraiment à vous de voir comment vous souhaitez faire vos tests. Donc je vais faire un nouveau test que je vais
00:05:45 :appeler test add to cart tout simplement et donc ce qu'on va tester à l'intérieur de cette méthode c'est quand on ajoute un produit dans le panier est-ce qu'on a bien le produit qui est ajouté et quand on l'ajoute de nouveau est-ce que la quantité de produit est modifiée puisque c'est ce qu'on fait
00:05:59 :à l'intérieur du model ici si le produit existe déjà et bien on va juste changer sa quantité et s'il n'existe pas encore on va l'ajouter dans le panier. Donc ici ce que je vais faire c'est déjà
00:06:10 :ajouter l'objet dans le panier donc on va utiliser cette fameuse méthode add to cart à partir de l'utilisateur. Là vous voyez que là encore je n'ai pas l'autocomplétion si j'essaie de faire
00:06:19 :add to cart ça ne marche pas ce qui me semble un petit peu bizarre puisque là on utilise directement shopper mais je vais tout simplement le spécifier en mettant là encore une annotation de type comme ça j'aurai bien la complétion automatique. Donc add to cart le slug on va
00:06:32 :dire donc que c'est égal à sneakers-dogstring comme ceci et donc la première chose qu'on va faire c'est vérifier qu'après avoir ajouté un élément dans le panier on a bien un article dans notre panier. Donc pour ça je vais faire un assert equal puisqu'on va vouloir tester un nombre donc
00:06:48 :une quantité on va tester en fait que le nombre d'articles qui sont dans le panier est égal à 1 donc pour ça on va récupérer le panier avec self.user.cart on va récupérer les articles avec
00:06:58 :.orders et on va utiliser tout simplement la méthode count qui nous permet de savoir combien d'éléments on a à l'intérieur d'un query set puisque là orders ça va nous retourner un query set si je retourne dans les modèles donc pas le modèle accounts mais le modèle de mon store si
00:07:13 :on va voir la classe cart ici vous voyez qu'on a une relation many to many fields dans un champ qu'on appelle orders avec la classe order ici donc cette relation many to many fields à partir du panier et bien ça va nous retourner donc ce qu'on a ici dans notre test donc c'est le fameux
00:07:28 :orders ici ça va nous retourner un query set et pour savoir combien d'éléments on a dans ce query set dans cette requête Django on va pouvoir utiliser count donc là ce qu'on souhaite vérifier c'est que ce compte est égal à 1 donc on a bien un seul article dans notre panier et on va également
00:07:43 :vérifier que cet article c'est bien les sneakers de dogstring donc là encore je vais refaire un assert equal on va récupérer le premier item du panier donc pour ça on va refaire user.cart.orders
00:07:55 :on va récupérer le premier élément donc dans ce cas ci on n'a qu'un seul élément donc on peut le récupérer avec .first et on va vérifier que cet élément donc qui est un article est bien que le
00:08:04 :produit associé à cet article il a bien le bon slog puisque là donc orders.first si je reviens là encore dans mes modèles on va récupérer un article puisque là orders c'est un champ là encore many to many fields qui est lié à order donc en récupérant le premier on va récupérer une instance
00:08:20 :de cette classe order et cette classe order on peut récupérer le produit donc c'est ce que je vais faire ici je veux dire .product et on va vérifier que le slog de ce produit est bien égal à
00:08:29 :sneakers de dogstring donc pour l'instant je vais pas aller plus loin je vais déjà tester tout ça je vais rouvrir un terminal et ici on va faire python manage.py test on va tester donc à l'intérieur
00:08:40 :de accounts.test.testmodels . et là c'est notre classe donc user test et on va mettre le nom de cette méthode ici test add to cart donc je lance là on aura pu mettre directement le accounts.test
00:08:54 :puisqu'en fait on n'a qu'une seule classe et qu'un seul test à l'intérieur de tout ça donc ça marcherait de la même façon ici en ciblant directement l'application accounts donc je valide avec entrée le test passe correctement je vais tester quand même en mettant une autre valeur pour vous montrer que ça ne fonctionne pas donc là on va dire 3 à la place de 1 et on
00:09:12 :devrait avoir une erreur puisque voilà on a un assertion error on s'attendait à avoir 1 et on a eu 3 à la place donc nos deux tests marchent bien pour l'instant et maintenant on va tester le deuxième cas de figure donc le cas de figure que l'on retrouve dans le cas où un article existe
00:09:25 :déjà dans le panier donc dans le cas où un article existe déjà dans le panier on va récupérer cet article et on va simplement incrémenter la quantité d'articles qu'on a dans ce panier donc je vais revenir dans mon test ici on va refaire donc cette ligne ici je vais la dupliquer
00:09:38 :je vais la mettre juste après ici et ensuite on va refaire en fait le assert equal on va vérifier qu'on a toujours bien un seul article dans le panier puisque là on ajoute le même article donc on ne va pas avoir deux articles on va avoir le même article sauf que la quantité cette fois de
00:09:52 :cet article aura été modifié donc on vérifie qu'on a bien un seul article toujours dans notre panier mais cette fois on va vérifier la quantité de cet article donc on va faire self.user.cartes.orders
00:10:04 :first et on va récupérer le quantity et on va vérifier qu'il est égal à 2 donc quantity ici c'est ce qu'on a dans notre modèle si je viens voir ici sur le modèle order on a un champ quantité donc quantity ici qui est un champ integer field donc on va avoir un nombre entier
00:10:20 :et ici je teste que quand on ajoute une deuxième fois ce produit à l'intérieur du panier et bien l'article associé dans le panier donc le first ici puisqu'on en a qu'un toujours dans notre panier et bien sa quantité est bien égale à 2 donc je relance mon test je vais rouvrir le terminal je
00:10:36 :lance le test et ça fonctionne donc on a bien un test qui a été correctement effectué donc là vous voyez qu'on a pas mal d'étapes à l'intérieur de ce test mais ça nous permet de vérifier que si on ajoute une première fois un article et une deuxième fois le même article et bien tout marche
00:10:49 :comme prévu on a bien le bon article qui est ajouté dans le panier donc ça c'est ce qu'on vérifie avec cette assertion ici on a bien le bon nombre d'articles donc un seul article à l'intérieur du panier et on a bien la bonne quantité donc là il ya certaines personnes qui
00:11:02 :pourraient vous dire que il vaut mieux séparer tout ça dans différents tests on pourrait en fait faire un premier test qui va uniquement vérifier que quand on ajoute un élément dans le panier et bien on a ces deux éléments qui sont vérifiés et ensuite faire un autre test qui
00:11:14 :vérifierait que la quantité est la bonne là c'est à vous de voir vraiment d'apprécier en fait ce que vous souhaitez faire dans ce cas ci je trouve qu'on n'a pas encore trop de choses à l'intérieur de ce test et que si jamais on avait le test qui ne fonctionne plus donc qui ne passe plus ce serait
00:11:27 :assez facile d'aller vérifier pourquoi le test ne passe plus et quelles sont les valeurs qu'on va récupérer dans les différentes étapes de ce test donc voilà pour cet exemple un peu plus complexe mais vous voyez que ça nous permet également de bien repenser notre code de modifier le code comme on l'a fait et de ne plus avoir trop de logique à l'intérieur des vues donc ça c'est
00:11:46 :quelque chose que vous allez faire le plus souvent en amont par la suite plus vous allez être habitué plus vous allez en fait dès le départ créer des modèles qui vont être les plus importants possible et des vues qui vont être assez légère bien sûr un projet ça évolue c'est tout à fait
00:12:01 :normal si vous avez parfois un peu trop de logique dans les vues et je trouve là encore que les tests sont un bon moyen de vérifier que vous pouvez avoir des choses qui sont les plus facilement testables possible et donc un code qu'il est donc facile de maintenir par la suite

Deviens membre Premium magic_button

Premium

Rechercher sur le site

Formulaire de contact

Inscris-toi à Docstring