Tests frontaux: quoi et comment tester, et quel outil utiliser?
J'ai écrit des tests pour mon code Ruby pendant un certain temps, mais en tant que développeur frontend, je suis évidemment intéressé à intégrer cela dans le code que j'écris pour mon code frontend. Il y en a plusieurs différents options avec lesquelles j'ai joué:
- CasperJS
- Capybara Rspec
- Jasmin
- Concombre ou juste Rspec
Qu'est-ce que les gens utilisent pour les tests? Et plus loin que testent les gens? Juste JavaScript? Liens? Formes? Contenu codé en dur?
Toute réflexion serait grandement appréciée.
J'ai eu les mêmes questions il y a quelques mois et, après avoir parlé à de nombreux développeurs et fait beaucoup de recherches, c'est ce que j'ai découvert. Vous devez tester votre JavaScript à l'unité, écrire un petit ensemble de tests d'intégration d'interface utilisateur et éviter les outils de test d'enregistrement et de lecture. Permettez-moi d'expliquer cela plus en détail.
Considérons d'abord la pyramide de test . Il s'agit d'une analogie intéressante créée par Mike Cohn qui vous aidera à décider quel type de test vous devez faire. Au bas de la pyramide se trouvent les tests unitaires, qui sont solides et fournissent une rétroaction rapide. Ceux-ci devraient être le fondement de votre stratégie de test et occuper ainsi la plus grande partie de la pyramide. En haut, vous avez les tests d'interface utilisateur. Ce sont les tests qui interagissent directement avec votre interface utilisateur, comme le fait Selenium par exemple. Bien que ces tests puissent vous aider à trouver des bogues, ils sont plus chers et fournissent des commentaires très lents. De plus, selon l'outil que vous utilisez, ils deviennent très fragiles et vous finirez par passer plus de temps à maintenir ces tests qu'à écrire du code de production réel. La couche de service, au milieu, comprend des tests d'intégration qui ne nécessitent pas d'interface utilisateur. Dans Rails, par exemple, vous testeriez votre interface REST directement au lieu d'interagir avec les éléments DOM.
Maintenant, revenons à votre question. J'ai découvert que je pouvais réduire considérablement le nombre de bogues dans mon projet, qui est une application web écrite en Spring Roo (Java) avec des tonnes de JavaScript, simplement en écrivant suffisamment de tests unitaires pour JS. Dans mon application, il y a beaucoup de logique écrite en JS et c'est le genre de chose que je teste ici. Je ne m'inquiète pas de l'apparence réelle de la page ou si les animations sont lues comme il se doit. Je teste si les modules que j'écris dans JS exécuteront la logique attendue, si les classes d'éléments sont correctement affectées et si les conditions d'erreur sont bien gérées. Pour ces tests, j'utilise Jasmine. Ceci est un excellent outil. Il est très facile à apprendre et possède de belles capacités de moquerie, appelées espions. Jasmine-jQuery ajoute des fonctionnalités plus intéressantes si vous utilisez jQuery. En particulier, il vous permet de spécifier des fixtures, qui sont des extraits du code HTML, vous n'avez donc pas à vous moquer manuellement du DOM. J'ai intégré cet outil avec maven et ces tests font partie de ma stratégie CI.
Vous devez être prudent avec les tests d'interface utilisateur, surtout si vous comptez sur des outils d'enregistrement/lecture comme Selenium. Étant donné que l'interface utilisateur change souvent, ces tests ne cessent de se casser et vous passerez beaucoup de temps à découvrir si les tests ont vraiment échoué ou s'ils sont juste obsolètes. De plus, ils n'ajoutent pas autant de valeur que les tests unitaires. Puisqu'ils ont besoin d'un environnement intégré pour fonctionner, vous n'aurez surtout envie de les exécuter qu'après avoir terminé le développement, lorsque le coût de la réparation est plus élevé.
Pour les tests de fumée/régression, cependant, les tests d'interface utilisateur sont très utiles. Si vous devez les automatiser, vous devez faire attention à certains dangers. Écrivez vos tests, ne les enregistrez pas . Les tests enregistrés reposent généralement sur des xpath générés automatiquement qui se cassent pour chaque petite modification que vous apportez à votre code. Je crois que Cucumber est un bon cadre pour écrire ces tests et vous pouvez l'utiliser avec WebDriver pour automatiser l'interaction du navigateur. Code pensant aux tests . Dans les tests d'interface utilisateur, vous devrez rendre les éléments plus faciles à trouver pour ne pas avoir à vous fier à des xpath complexes. L'ajout d'éléments de classe et id là où vous ne le feriez pas habituellement sera fréquent. N'écrivez pas de tests pour chaque petit cas de coin. Ces tests sont coûteux à écrire et prennent trop de temps à s'exécuter. Vous devez vous concentrer sur les cas qui explorent la plupart de vos fonctionnalités. Si vous écrivez trop de tests à ce niveau, vous testerez probablement la même fonctionnalité que vous avez déjà testée sur vos tests unitaires (en supposant que vous les ayez écrits).
Dans mon projet actuel, j'utilise Spock et Geb pour écrire les tests d'interface utilisateur. Je trouve ces outils incroyables. Ils sont écrits en Groovy, ce qui convient mieux à mon Java.
Il existe de nombreuses options et outils pour cela. Mais leur choix dépend de si vous avez une interface utilisateur Web ou s'il s'agit d'une application de bureau?
Supposons que les outils que vous avez mentionnés sont l'interface utilisateur Web. Je suggère Selenium (alias WebDriver): http://seleniumhq.org/docs/
Il existe une variété de langues qu'il prend en charge (Ruby est dans la liste). Il peut être exécuté sur une variété de navigateurs, et il est assez facile à utiliser avec de nombreux tutoriels et conseils disponibles. Oh, et c'est gratuit, bien sûr :)
Je pense que comme ce message reçoit beaucoup de likes, je publierais ma réponse à ma question car j'écris beaucoup de tests maintenant et comment vous testez le front-end a beaucoup évolué maintenant.
Donc, en termes de tests FE, j'ai passé beaucoup de temps à utiliser karma avec Jasmine , bien que le karma fonctionnera bien avec d'autres suites de tests comme mocha & qunit. Bien que ceux-ci soient excellents, le karma vous permet d'interfacer directement avec les navigateurs pour exécuter vos tests. L'inconvénient est que lorsque votre suite de tests devient volumineuse, elle peut devenir assez lente.
Alors récemment, je suis passé à Jest qui est beaucoup plus rapide et si votre application réagit à l'écriture, l'utilisation de enzyme avec des tests instantanés vous donne une très bonne couverture. Parler de couverture Jest a une couverture d'Istanbul intégrée et configurée et se moquer est vraiment simple et facile à utiliser. L'inconvénient qu'il ne teste pas dans le navigateur et qu'il utilise quelque chose appelé jsdom qui est rapide, mais a quelques inconvénients. Personnellement, je ne trouve pas cela très important, en particulier lorsque je compile mon code via webpack/babel, ce qui signifie que les bogues du navigateur sont assez rares, donc ce n'est généralement pas un problème si vous testez manuellement de toute façon (et imo vous devriez ).
En termes de travail dans la pile Rails, c'est beaucoup plus facile maintenant que la gemme de webpacker est maintenant disponible et l'utilisation de npm et du nœud est généralement beaucoup plus exceptée. Je recommanderais d'utiliser nvm pour gérer vos versions de nœuds
Bien que ce ne soit pas strictement des tests, je recommanderais également d'utiliser des peluches car cela ramasse également beaucoup de problèmes dans votre code. Pour JS j'utilise eslint avec plus joli et scss/css j'utilise stylelint
En ce qui concerne les éléments à tester, je pense que Carlos parle de la pyramide des tests qui est toujours pertinente, après tout, la théorie ne change pas, juste les outils. J'ajouterais aussi d'être pratique sur les tests, je testerais toujours, mais à quel niveau et couverture dépendra du projet. Il est important de gérer votre temps et vos heures/jours à tester un projet à cycle de vie court. Projets de plus grande envergure/à plus long terme, les avantages d'une plus grande suite de tests sont évidemment plus importants.
Quoi qu'il en soit, j'espère que cela aide les gens qui examinent la question.