Tests

• Pix-Live
  • Framework de tests
  • Exécuter les tests
  • Typologies de tests
• Pix-API

Pix-Live

Framework de 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 faite grâce au plugin ember-cli-mocha.

Exécuter les tests

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.

Typologies de tests

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)

Pix-API

Stratégie de tests

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.

Types de tests

Test d'intégration

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édifini, 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.