Les tests automatisés constituent un excellent moyen de protéger votre code contre les régressions futures. Beaucoup de personnes savent comment le faire dans notre base de code Rails avec rspec, mais le côté JavaScript peut sembler un peu mystérieux pour certains.
Heureusement, il est assez facile de nos jours d’ajouter des tests de base à votre code Ember !
Tests de composants
Dans le tutoriel précédent de cette série, nous avons ajouté un composant nommé fancy-snack pour afficher notre collation avec un fond qui s’estompe. Écrivons un test pour celui-ci. Créez le fichier suivant :
test/javascripts/components/snack-test.js
import componentTest from "helpers/component-test";
moduleForComponent("fancy-snack", { integration: true });
componentTest("test the rendering", {
template: "{{fancy-snack snack=testSnack}}",
setup() {
this.set("testSnack", {
name: "Potato Chips",
description: "Now with extra trans fat!",
});
},
test(assert) {
assert.equal(this.$(".fancy-snack-title h1").text(), "Potato Chips");
assert.equal(
this.$(".fancy-snack-description p").text(),
"Now with extra trans fat!"
);
},
});
Pour exécuter le test, ouvrez votre navigateur sur votre serveur de développement à l’adresse /qunit?module=component%3Afancy-snack. Votre navigateur exécutera alors les tests de composant et affichera un résultat du type « 2 assertions sur 2 réussies, 0 échouées. »
Notez que lorsque vous êtes sur la page /qunit, vous pouvez exécuter d’autres tests. Il vous suffit de sélectionner un nouveau test dans le menu déroulant Module en haut de l’écran.
Parcourons le test pour comprendre comment il fonctionne.
La ligne template indique à Ember comment nous souhaitons insérer notre composant. C’est exactement la même balise que vous utiliseriez pour placer le composant dans un modèle handlebars, elle devrait donc vous être familière :
template: '{{fancy-snack snack=testSnack}}’,
Notez qu’elle passe testSnack en tant que paramètre snack. Celui-ci est défini dans la méthode setup() :
setup() {
this.set('testSnack', {
name: 'Potato Chips',
description: 'Now with extra trans fat!'
});
},
J’ai simplement inséré quelques données fictives. C’est tout ce qu’il faut faire pour que Ember affiche le composant. Enfin, nous avons quelques assertions dans la méthode test() :
test(assert) {
assert.equal(this.$('.fancy-snack-title h1').text(), 'Potato Chips');
assert.equal(this.$('.fancy-snack-description p').text(), 'Now with extra trans fat!');
}
Si vous utilisez this.$(), vous accédez à un sélecteur jQuery dans votre modèle. Les assertions ici utilisent ce sélecteur pour récupérer la valeur du titre de la collation et de sa description, puis les comparent à ce que nous attendons. Si les valeurs correspondent, les assertions réussissent et notre test fonctionne correctement.
Il est à noter que vous n’avez pas besoin de tester chaque petit détail d’un composant comme celui-ci. Vous devriez faire preuve de discernement et essayer de déterminer quels éléments de votre code sont susceptibles de casser ou de causer des confusions aux autres développeurs à l’avenir. Si vous testez trop de choses dans votre modèle, cela rendra plus difficile pour quelqu’un d’autre de le modifier plus tard. Commencez petit, en testant les choses les plus évidentes, et avec le temps, vous prendrez l’habitude.
Tests d’acceptation
Les tests d’acceptation sont souvent plus faciles à écrire et peuvent être plus puissants que les tests de composants, car ils testent votre application de la même manière qu’un utilisateur le ferait dans son navigateur. Je commence souvent par les tests d’acceptation, puis, si je crée un composant complexe, j’ajoute également des tests pour celui-ci.
Voici comment nous pouvons écrire un test d’acceptation qui visitera notre route /admin/snack et confirmera que la collation a été affichée :
test/javascripts/acceptance/snack-test.js
import { acceptance } from "helpers/qunit-helpers";
acceptance("Snack");
test("Visit Page", function (assert) {
visit("/admin/snack");
andThen(() => {
assert.ok(exists(".fancy-snack-title"), "the snack title is present");
});
});
Dans ce cas, test() se lit presque comme de l’anglais ! La première commande indique de visiter l’URL /admin/snack. Ensuite, il y a une méthode andThen(). Cette méthode est nécessaire pour s’assurer que tout le travail en arrière-plan est terminé avant que les tests ne continuent. Étant donné que le code JavaScript et Ember est asynchrone, nous devons nous assurer qu’Ember a terminé tout ce qu’il avait à faire avant que nos assertions ne soient exécutées. Enfin, le test vérifie si l’élément .fancy-snack-title est présent.
Cependant, si vous exécutez ce test en visitant /qunit?module=Acceptance%3A%20Snack, vous constaterez que le test échouera, en raison d’une erreur AJAX.
Si vous vous en souvenez, notre code comprend à la fois un côté Rails et un côté JavaScript qui a effectué une requête AJAX pour récupérer ses données. Le test d’acceptation a exécuté le côté JavaScript, mais il ne savait pas quoi faire pour récupérer ses données depuis Rails.
Pour corriger cela, nous devons ajouter une réponse factice en utilisant la excellente bibliothèque pretender. Ouvrez le fichier test/javascripts/helpers/create-pretender.js et recherchez la ligne qui dit :
this.get("/admin/plugins", () => response({ plugins: [] }));
Juste en dessous, ajoutez une ligne pour retourner un objet de collation factice afin que notre test d’acceptation puisse fonctionner :
this.get("/admin/snack.json", () => {
return response({ name: "snack name", description: "snack description" });
});
Vous pouvez lire le code ci-dessus comme suit : « pour toute requête vers /admin/snack.json, répondre avec la response suivante. »
Si vous actualisez l’URL /qunit?module=Acceptance%3A%20Snack, votre test d’acceptation devrait récupérer ses données via pretender et les tests devraient réussir.
Où aller dès maintenant
Vous pourriez essayer de construire une petite fonctionnalité et d’ajouter des tests pour vous assurer qu’elle fonctionne. Vous pourriez même essayer d’utiliser le TDD en créant vos tests avant d’écrire du code côté front-end. Selon ce sur quoi vous travaillez et vos préférences personnelles, vous pourriez trouver cette approche plus agréable. Bonne chance et bon codage 
Ce document est sous contrôle de version - suggérez des modifications sur github.