paris js#35 - stratégie de tests d'une application mvc
DESCRIPTION
Présentation d'une stratégie de tests : - la façon de gérer l'asynchronisme d'une application one page BackboneJS, ou plus globalement d'une application MVC - la façon de gérer les requêtes aux API via un fake server sinon Pour plus d'infos, des retours ou questions : @gmajoulet sur TwitterTRANSCRIPT
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