-
Notifications
You must be signed in to change notification settings - Fork 20
Tests
Le framework de test par défaut proposé par Ember.js est QUnit.
Nous estimons que ce framework est aujourd'hui dépassé et en retard en termes de communauté, fonctionnalités, intégrations support et évolution, par rapport à d'autres frameworks tels que Jasmine ou Mocha. C'est pourquoi nous avons fait le choix de le remplacer par ce dernier, considéré comme la référence dans l'écosystème JS depuis plusieurs années (un exploit dans le monde JS!).
Le remplacement de QUnit par Mocha s'est fait grâce au plugin ember-cli-mocha.
L'exécution des tests se fait via la commande ember test (ou ember t). Il est possible de rejouer automatiquement les tests à chaque changement via la commande ember test --serve.
Il est possible de jouer directement les tests (sans passer par ember test) lorsque l'application est lancée (via ember serve ou ember s). Pour ce faire, il faut accéder à l'URL http://localhost:4200/tests.
Pour lancer un sous-ensemble défini de tests, on peut utiliser l'option --filter, par exemple : ember test --filter="assessments".
Le filtrage peut se faire aussi directement au niveau des tests (plutôt que du CLI), grâce aux options Mocha skip et only.
Il est également possible de lancer les tests avec ember exam, commande strictement compatible avec ember test, avec quelques options supplémentaires disponibles. Par exemple, il est possible de lancer ses tests en parallèle.
Voir la documentation d'ember-exam.
Ember.js permet de concevoir 3 types de tests :
-
unitaires : La définition d'un test unitaire est le test d'une fonction prise en complète isolation. Nous nous en servons pour :
- computed properties,
- serializers,
- adapters,
- helpers,
- services,
- utils
-
intégration : pour vérifier le rendu et le comportement d'un composant.
-
acceptance : Bien que nommés "acceptance" par Ember il ne s'agit pas de vrais tests d'acceptances, bout-en-bout, qui vérifient toute la chaîne. Ces tests ont lieu avec un backend bouchonnés par Mirage, c'est donc la partie front uniquement qui est testée en "boîte noire". Ils servent à :
- vérifier l'accès aux routes,
- vérifier les accès par URL,
- vérifier les transitions,
- vérifier que les composants communiquent bien entre eux,
- les requêtes sortantes (par exemple : la sauvegarde d'une réponse par l'utilisateur)
Il est toujours possible de déboguer les tests uniquement avec des console.log bien placé – mais ça devient assez vite limitant.
Heureusement tous les tests peuvent s'exécuter dans un navigateur web – ce qui donne accès aux outils de déboguage web habituels. Pour cela, il suffit d'ouvrir l'URL en haut de la console Testem dans un navigateur.
Cela permet de :
- Utiliser des
console.log(tous tests) : les logs seront affichés dans la console Testem (pour phantom) ou dans le navigateur web. - Utiliser le débogueur du navigateur (tous tests) : ouvrir l'onglet "Sources" de la console de développement, et placer des breakpoints dans le test – puis recharger la page pour relancer les tests.
- Utiliser l'inspecteur web (tests de composants) : rajouter
return new Ember.RSVP.Promise(function(){});dans un test de composant permet d'utiliser l'inspecteur web du navigateur pour inspecter le DOM du composant. - Utiliser l'Inspecteur Ember (tests d'acceptance) : rajouter
return pauseTest()dans un test d'acceptance permet d'utiliser le navigateur pour inspecter l'application en live. On peut même utiliser l'Inspecteur Ember pour observer l'état des composants et des modèles.
Lorsqu'une fonction est testée avec de nombreux cas d'input, il est courant sur pix de créer un tableau avec tout les cas à tester. Dans le cas où les exemples d'input et output ne suffisent pas à comprendre le cas de test, il faudra rajouter un when dans le cas à tester. Il est nécessaire de rajouter le when dans la situation quand
- les cas de tests ne sont pas assez explicites juste à la vue de l'input et l'output de la fonction
- si un développeur tiers ne comprend pas immédiatement le cas de test sans un when.
Exemple où le when n'a pas été nécessaire
Exemple où le when a été nécessaire
Il existe 2 type de tests : les tests d'intégrations, qui testent l'API en "boîte noire", et les tests unitaires, qui testent chaque fonction en isolation.
En écrire le moins possible, uniquement le cas nominal de votre story.
- Un test d'intégration requiert un setup important : mettre la base de données dans un état prédéfini, couper les requêtes internet avec NockJS...
- Si on devait couvrir toutes les fonctionnalités avec les seuls tests d'intégration, nous ferions face à une explosion combinatoire du nombre de cas, en clair, quasi impossible de couvrir correctement l'application sans écrire des milliers de tests
Pour ces 2 raisons, nous tendons à écrire le plus possible de tests unitaires et le moins possible de tests d'intégration.
Il s'agit de tester une seule fonction en complète isolation.
- il est parfois utile de stubber une fonction privée, même si elle ne se connecte pas à l'extérieur de l'application, pour éviter l'explosion combinatoire.
- on teste en général uniquement les fonctions publiques d'un module ES6