Accueillir! Heureux de vous voir dans la sixième partie de ma série de résumés Vuejs Amsterdam Conference 2022, dans laquelle je partage avec vous un résumé de toutes les discussions. Vous pouvez lire ma série de résumés de la JSWorld Conference 2022 (en quatre parties) , où j'ai résumé toutes les discussions de la première journée. Vous pouvez également retrouver les précédents Talks de la conférence Vue Amsterdam 2022 sur mon blog. ici (Récurrent) Présentation Après deux ans et demi, JSWorld et Vue Amsterdam Conference étaient de retour au Theater Amsterdam entre le 1er et le 3 juin, et j'ai eu la chance d'assister à cette conférence pour la première fois. J'ai appris beaucoup de choses, rencontré beaucoup de gens formidables, parlé avec de grands développeurs et passé un bon moment. Le premier jour, la Conférence JSWorld a eu lieu, et les deuxième et troisième jours, la Vue Amsterdam. La conférence a été pleine d'informations avec d'excellents orateurs, chacun d'entre eux m'a appris quelque chose de précieux. Ils voulaient tous partager leurs connaissances et leurs informations avec d'autres développeurs. J'ai donc pensé que ce serait formidable si je pouvais continuer à le partager et aider les autres à l'utiliser. Au début, j'ai essayé de partager quelques notes ou diapositives, mais je trouvais que ce n'était pas assez bon, du moins pas aussi bon que ce que l'orateur partageait avec moi. J'ai donc décidé de revoir chaque discours, de les approfondir, de rechercher, de prendre des notes et de les combiner avec leurs diapositives et même leurs mots exacts dans leur discours, puis de le partager avec vous afin que ce que je partage avec vous soit au moins à au même niveau que ce que j'ai appris d'eux. Un point très important et j'ai seulement essayé de les apprendre pour pouvoir les transformer en ces articles. Même Cela signifie que si vous apprenez quelque chose de nouveau, c'est grâce à leurs efforts. (Donc, si vous voyez de la désinformation, blâmez-les, pas moi, n'est-ce pas? xD) Tout ce que vous lisez au cours de ces quelques articles est le résultat de l'effort et du temps de l'orateur lui-même, la plupart des phrases écrites dans ces articles sont exactement ce qu'elles ont dit ou ce qu'elles ont écrit dans Slides. Enfin et surtout, je ne peux pas creuser dans tous les détails techniques ou les codages en direct dans certains des discours. Mais si vous êtes intéressé et avez besoin de plus d'informations, faites-le moi savoir et j'essaierai d'écrire un article plus détaillé séparément. Aussi, n'oubliez pas de consulter leur Twitter/Linkedin. Vous trouverez le programme de la conférence. ici C'est un piège (de test) ! Les pièges courants des tests et comment les résoudre - Développeur logiciel chez shopware Ramona Schwering "C'est un piège" - un appel ou un sentiment que nous connaissons tous, pas seulement en ce qui concerne Star Wars. Cela signale un moment soudain où vous remarquez un danger imminent. Cette situation est une excellente allégorie d'une réalisation désagréable en test. Imaginez que vous ayez les meilleures intentions en matière de tests, mais que vous vous retrouviez toujours avec des tests qui ne vous apportent aucune valeur ? Des tests qui vous semblent pénibles à gérer ? Lors de l'écriture de tests frontend, il y a beaucoup de pièges sur le chemin. En somme, ils peuvent entraîner une maintenabilité médiocre, un temps d'exécution lent et, dans le pire des cas, des tests auxquels vous ne pouvez pas faire confiance. Mais le pire problème, ce sont ces tests qui vous donnent une nouvelle valeur et un nouveau résultat parce qu'ils sont feuilletés. Vous avez une construction qui parfois réussit et parfois échoue et vous n'avez rien fait entre les deux. Points douloureux Vous pouvez être sûr que les tests présentent de nombreux avantages et avantages, mais toutes ces choses merveilleuses peuvent être éclipsées par des points douloureux causés par diverses raisons. Toutes les choses que vous avez faites avec les meilleures intentions mais qui, à long terme ou même plus tôt, se sont avérées douloureuses ou épuisantes. Par exemple, des tests lents peuvent tuer le plaisir. Imaginez que vous ayez votre demande d'extraction et que vous souhaitiez qu'elle soit fusionnée, mais que vous deviez attendre des heures, voire des jours, pour que le pipeline soit enfin terminé. Pire encore, les tests sont pénibles à maintenir. Vous pensez à votre passé et vous demandez : qu'avez-vous fait de ce test ? Quel était le but ?! Qu'as-tu pensé de celui-là ? Ou d'autres membres de l'équipe qui vous posent des questions sur ce que vous avez fait dans le passé et dont vous n'avez aucune idée. Mais le pire problème, ce sont ces tests qui vous donnent une nouvelle valeur et un nouveau résultat parce qu'ils sont feuilletés. Vous avez une construction qui parfois réussit et parfois échoue et vous n'avez rien fait entre les deux. Essais simples Il n'a pas à être de cette façon. L'un des états d'esprit et des règles d'or les plus importants dans les meilleures pratiques de test JavaScript est simple. Les tests doivent être conçus simplement et simplement dans tous les cas. Dans les tests unitaires, les tests d'intégration et les tests de bout en bout, restez simple. Notre objectif devrait être que l'on soit capable de comprendre votre test et d'obtenir son intention instantanément sans y penser. Essayez de viser une conception de test plate, ce qui signifie ne tester que la quantité nécessaire et utiliser peu ou pas d'abstractions du tout. Pièges Regardons le premier piège. describe('deprecated.plugin', () => { it('should throw error',() => { … }); }); Il devrait renvoyer une erreur si le plug-in obsolète est en cours d'utilisation. Lorsque vous regardez le titre - devrait générer une erreur - vous ne savez pas ce qu'il veut accomplir. Mais la règle d'or dit que vous devez savoir instantanément ce qu'il fait. Nous pouvons le rendre plus compréhensible avec la «règle des trois parties». Le titre du test doit contenir trois éléments : Ce qui est testé Dans quelles circonstances doit-on tester Quel est le résultat attendu Avec cette règle à l'esprit, voici à quoi ressemblera notre test : describe('deprecated.plugin', () => { it('Property: Should throw an errorif the deprecated prop is used', () => { … }); }); Le prochain piège peut être la structure de test : describe('Context menu', () => { it('should open the context menu on click', async () => { const wrapper = createWrapper(); expect(wrapper.vm).toBeTruthy(); await wrapper.trigger('click'); const selector = '.sw-context-menu'; expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); }); Dans ce cas, les déclarations, les actions et les assertions sont écrites partout sans aucune structure claire. Surtout dans les tests plus importants, cela peut être une énorme douleur. Nous pouvons le rendre plus structuré avec AAA Pattern. Vous divisez votre test en trois parties : Organiser : tout ce qui concerne la configuration du scénario que le test vise à simuler. Actions : Exécuter votre unité sur le test et suivre les étapes pour arriver à l'état des résultats. Assert : Où vous pouvez faire les assertions et vérifier votre scénario de test. Voici à quoi ressemble notre test avec AAA Pattern : describe('Context menu', () => { it('should open the context menu on click', () => { // Arrange const wrapper = createWrapper(); const selector = '.sw-context-menu'; // Act await wrapper.trigger('click'); // Assert expect(wrapper.vm).toBeTruthy(); expect(wrapper.find(selector).isVisible()).toBeTruthy(); }); }); Cela a l'air beaucoup mieux ! Mais il y a un problème. Repensez à notre cas de test. C'est un menu contextuel et il est caché par défaut. Nous devons donc l'ouvrir pour interagir avec lui. Mais cela signifie que nous devons faire une affirmation pour nous assurer qu'il est ouvert avant l'acte. Cela ne détruit-il pas le modèle ? Si nous testons le DOM, nous devons parfois vérifier les états avant et après. Jetons donc un coup d'œil à ce modèle sous un autre angle. … organiser mon test == ce qu'on me . donne …agir dans mon test == quelque chose arrive. quand … affirmer les résultats == quelque chose se passe c'est ce que j'attends comme résultat. alors Il s'agit d'un modèle tiré du développement axé sur le comportement : Étant donné - Quand - Alors Notre test précédent avec l'utilisation de ce modèle : describe('Context menu', () => { it('should open the context menu on click', () => { // Given const contextButtonSelector = 'sw-context-button'; const contextMenuSelector = '.sw-context-menu'; // When let contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(false); const contextButton = wrapper.find(contextButtonSelector); await contextButton.trigger('click'); // Then contextMenu = wrapper.find(contextMenuSelector); expect(contextMenu.isVisible()).toBe(true); }); }); Test E2E Évitez d'utiliser des espaces réservés et utilisez autant que possible des noms réalistes. it('should create and read product', () => { … cy.get('.sw-field—product-name').type('T-Shirt Ackbar'); cy.get('.sw-select-product__select_manufacturer') .type('Space Company'); … }); Si vous ne voulez pas trouver des milliers de noms, vous pouvez peut-être utiliser un truqueur ou d'autres outils pour générer des données factices, ou si les lois et votre projet sont d'accord, importez-les depuis l'état de production. Assurez-vous simplement que votre test reste compréhensible et facile à lire et que vous savez ce qu'il fait. Jetons un coup d'œil au même test pour le piège suivant, qui est les sélecteurs. Si vous refactorisez votre application et modifiez certaines classes - ce qui est courant - cela pourrait entraîner l'échec de votre test, et dans ce cas, le test échoue sans qu'un bogue ne soit présent dans votre application - ce qui s'appelle un faux négatif ne donnant aucun rapport fiable de votre app parce qu'il n'est pas cassé, juste votre implémentation a changé. Regardez les sélecteurs que vous devez ! En d'autres termes, vous ne devez pas tester les détails d'implémentation. Au lieu de cela, pensez à utiliser des éléments sur lesquels un utilisateur attirerait l'attention et à naviguer dans votre application. Par exemple, du texte à l'intérieur de votre page. Mieux encore, utilisez des sélecteurs qui ne sont pas susceptibles de changer, comme les attributs de données. Vous pouvez même l'appeler par exemple pour cypress afin que l'on sache instantanément qu'il est destiné à des tests. data-cy=”submit” Enfin et surtout, n'utilisez pas de temps d'attente fixes. Cypress.Commands.add('typeSingleSelect', { prevSubject: 'element', }, (subject, value, selector) => { … cy.wait(500); cy.get(`${selector} input`) .type(value); }); D'une part, cela peut trop ralentir votre test si un cas de test est exécuté autant de fois. Cela peut être encore pire lorsque votre application est utilisée sur un matériel plus faible. Dans ce cas, vous aurez peut-être besoin de plus que ce correctif de 500 ms. Il existe des solutions pour cela, par exemple attendre les changements dans l'interface utilisateur, comme un spinner de chargement pour disparaître ou une animation pour s'arrêter ou quelque chose pour apparaître. Ou encore mieux, attendez les requêtes et les réponses de l'API. Les tests sont là pour vous comme un assistant, pas comme un obstacle. Ils devraient ressembler à une routine et non à la résolution d'une formule mathématique complexe. Fin du sixième discours J'espère que vous avez apprécié cette partie et qu'elle peut être aussi précieuse pour vous qu'elle l'était pour moi. Au cours des prochains jours, je partagerai le reste des discussions avec vous. Restez à l'écoute… Également publié . ici
