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é par l’introduction de ce code dans mon code frontal. Il y a pas mal d’options différentes avec lesquelles j’ai joué avec:

  • CasperJS
  • Capybara & Rspec
  • Jasmin
  • Concombre ou juste Rspec

Qu’est-ce que les gens utilisent pour les tests? Et plus loin que ce que les gens testent? Juste JavaScript? Liens? Formes? Contenu codé?

Toute pensée serait grandement appréciée.

    Il y a quelques mois, j’ai eu les mêmes questions et, après avoir parlé à de nombreux développeurs et fait beaucoup de recherches, c’est ce que j’ai découvert. Vous devriez tester votre JavaScript, écrire un petit ensemble de tests d’intégration d’interface utilisateur et éviter les outils de test d’enregistrement et de lecture. Laissez-moi expliquer cela plus en détail.

    Tout d’abord, considérez la pyramide de test . Ceci est une analogie intéressante créée par Mike Cohn qui vous aidera à décider quel type de test vous devriez faire. Au bas de la pyramide se trouvent les tests unitaires, qui sont solides et fournissent un retour rapide. Celles-ci devraient constituer le fondement de votre stratégie de test et occuper ainsi la plus grande partie de la pyramide. En haut, vous avez les tests de l’interface utilisateur. Ce sont les tests qui interagissent directement avec votre interface utilisateur, comme le fait par exemple Selenium. Bien que ces tests puissent vous aider à trouver des bogues, ils sont plus coûteux et fournissent une rétroaction très lente. 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 ne nécessitant pas d’interface utilisateur. Dans Rails, par exemple, vous testeriez directement votre interface REST 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 dans 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 de la manière dont les animations se jouent comme elles le devraient. Je teste si les modules que j’écris dans JS exécuteront la logique attendue, si les classes d’éléments sont correctement atsortingbuées et si les conditions d’erreur sont bien gérées. Pour ces tests, j’ai utilisé Jasmine. C’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 supplémentaires 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 à simuler manuellement le DOM. J’ai intégré cet outil à maven et ces tests font partie de ma stratégie de CI.

    Vous devez faire attention aux tests de l’interface utilisateur, surtout si vous utilisez des outils d’enregistrement / lecture tels que Selenium. Étant donné que l’interface utilisateur change souvent, ces tests continuent de se briser et vous passerez beaucoup de temps à déterminer si les tests ont vraiment échoué ou s’ils sont simplement obsolètes. En outre, ils n’apportent pas autant de valeur que les tests unitaires. Comme ils ont besoin d’un environnement intégré pour s’exécuter, vous aurez surtout tendance à les exécuter uniquement après avoir fini de développer, lorsque le coût de la réparation est plus élevé.

    Pour les tests de fumée / régression, cependant, les tests de l’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 xpaths générés automatiquement qui se brisent pour chaque petite modification apscope à 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 de l’interface utilisateur, vous devrez rendre les éléments plus faciles à trouver afin de ne pas avoir à vous fier à des xpath complexes. Ajouter des éléments de classe et d’ID là où vous ne le feriez habituellement sera fréquent. N’écrivez pas de tests pour chaque petit cas en coin. Ces tests sont coûteux à écrire et prennent trop de temps à fonctionner. 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 les mêmes fonctionnalités que vous avez déjà testées sur vos tests unitaires (en supposant que vous les ayez écrites).

    Dans mon projet actuel, j’utilise Spock et Geb pour écrire les tests de l’interface utilisateur. Je trouve ces outils incroyables. Ils sont écrits en Groovy, ce qui convient mieux à mon projet Java.

    Il y a beaucoup d’options et d’outils pour cela. Mais leur choix dépend de votre interface Web ou de votre application de bureau?

    À partir des outils dont vous avez parlé, il s’agit de l’interface Web. Je suggère Selenium (aka WebDriver): http://seleniumhq.org/docs/

    Il prend en charge une variété de langues (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 astuces. Oh, et c’est gratuit, bien sûr 🙂

    Comme ce post a beaucoup de goûts, je posterais 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 le karma avec Jasmine , bien que le karma fonctionnera bien avec d’autres suites de tests comme moka et qunit. Bien que ce soit génial et que le karma vous permette d’interagir directement avec les navigateurs pour exécuter vos tests. L’inconvénient est que votre suite de tests grandit, elle peut devenir assez lente.

    Donc, récemment, je suis passé à Jest, qui est beaucoup plus rapide et si votre application d’écriture réagit, l’utilisation d’ enzymes avec des tests instantanés vous donne une très bonne couverture. Parler de la couverture Jest a la couverture d’Istanbul intégrée et mise en place et se moquer est vraiment facile à utiliser. L’inconvénient est qu’il ne teste pas dans le navigateur et qu’il utilise quelque chose appelé jsdom qui est rapide, mais qui présente quelques nuisances. Personnellement, je ne trouve pas cela particulièrement grave lorsque je comstack mon code via webpack / babel, ce qui signifie que les bogues entre navigateurs sont assez rares, donc généralement, ce n’est pas un problème si vous testez manuellement ).

    En ce qui concerne le travail dans la stack des rails, il est désormais très facile d’avoir désormais access au gem Webpacker et d’utiliser npm et node beaucoup plus facilement. Je recommande d’utiliser nvm pour gérer vos versions de nœuds

    Bien que cela ne soit pas ssortingctement un test, je vous recommande également d’utiliser le linting, car il détecte également de nombreux 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 lorsque Carlos parle de la pyramide de test, elle est toujours pertinente, après tout, la théorie ne change pas, juste les outils. J’appendais aussi être pratique sur les tests, je testerais toujours, mais à quel niveau et la couverture dépendront du projet. Il est important de gérer votre temps et de passer des heures / jours à tester un projet de cycle de vie court. Des projets de plus grande envergure ou à plus long terme, les avantages d’une suite de tests plus grande sont évidemment plus importants.

    Quoi qu’il en soit, j’espère que cela aidera les gens qui examinent la question.