Paris js#35 - Stratégie de tests d'une application MVC

Stratégie de testsParisJS #35

Présentation

● Développeur JavaScript● Bientôt 2 ans chez Wisembly

Objectifs

● Retour d’expérience● Comment tester une app MVC● Revue des solutions mises en oeuvre● Exemples de code

Wisembly

Wisembly

Une test suite

● Pourquoi● Quels objectifs

Techno frontend

● BackboneJS● Backbone Layout Manager● Backbone Relational● WebSockets

Techno de tests

● Mocha / expect● Sinon● PhantomJS / Mocha-phantomjs

Choix du type de tests

● Unitaires● Fonctionnels

Premier test

My first test It should spread some love ‘Tendresse et chocolat’ should be a string

Premier test de l’app

● On clique sur le premier élément du menu● On vérifie qu’il y a 4 items sur la page

Test asynchrone bullshit

● Une fois le test terminé, on exécute `done`

Test asynchrone et dispatcher

● On trigger des events à chaque `render`

Bien cloisonner les tests

● Les tests ne doivent pas être inter dépendants

● S’assurer que toutes les actions asynchrones sont terminées

Promises manager

● Stocker toutes les promises `request` et `render`

● afterAll filtrable par namespace

Test asynchrone indépendant

Requête API

● Que fait on de cette data● C’est long● Browsers, mises à jour

Fake server

● Sinon.js● Avantages

○ Qualité○ Hygiène de la test suite○ Process

● Inconvénients○ Mise en place (selon les cas)○ Maintenance

Fake server - mise en place

● Facile et rapide à mettre en place● Parfois complexe de simuler l’API

Merci

Des questions, des conseils ?

Twitter : @gmajoulet