Javascript : "Fullstack" le développement front, le développement back, les optimisations. Un framework nait tous les jours, ces planches présentent des solutions qui, fin 2015, sont adoptées et permettent la mise en place d'applications rapides, dynamiques, ergonomiques et simples.
2. 2 / 67
● Genèse et principes de fonctionnementGenèse et principes de fonctionnement
de Javascriptde Javascript
3. 3 / 67
Pourquoi développer une application en Javascript ?Pourquoi développer une application en Javascript ?
● Avec la digitalisation de nombreux usages, les architectures ont
du prendre en compte différentes évolutions
● De plus en plus d'interactions entre les données.
● De plus en plus de données hébergées en distant.
● De plus en plus de variété d'équipements et d'usages.
● Depuis plusieurs années, on assiste à un mouvement fort de
développement de services distants.
● L'utilisateur a l'exigence d'une une expérience “desktop”,
difficilement compatible avec la conception classique
d'applications “web” :
● 1. L'utilisateur envoie une requête...
● 2. Le serveur génère toute la page HTML en résultant.
4. 4 / 67
Pourquoi développer une application en Javascript ?Pourquoi développer une application en Javascript ?
● Javascript à la rescousse
● Nouvelle approche : redéfinir les responsabilités entre
client et serveur.
● Avantages : pas d'état sur le serveur, possibilité de
traitement “full-offline”, meilleure fluidité ressentie.
● Inconvénients : moins de maîtrise de l'environnement
impliquant des contraintes supplémentaires côté
sécurité.
5. 5 / 67
GenèseGenèse
● Javascript est un « vieux » langage
● Créé en 1995 par Netscape
● Langage de script à héritage prototypal, typé dynamiquement et
offrant des « first class functions ».
● Javascript est inclus dans tous les navigateurs du marché
● On le désigne par conséquent comme la lingua franca de la
programmation web.
● La non évolution des navigateurs entre 1999 et 2006 a aussi
impacté Javascript
● Le langage est considéré jusqu'en 2006 comme un langage
«amateur» permettant d'animer une image où d'assurer le
tracking des utilisateurs à des fins commerciales.
6. 6 / 67
GenèseGenèse
● Les précurseurs
● Gmail : 2004 (Google)
● jQuery : 2006 (John Resig)
● L'arrivée de Google Chrome
● Apparu fin 2008
● Une compétition sur la rapidité d’exécution de Javascript est
engagée ! Elle qui aboutit à un meilleur support et de bonnes
performances sur l'ensemble des navigateurs
● De nouveaux défis
● Comment développer des applications larges et complexes en
ayant le navigateur comme environnement d’exécution ?
7. 7 / 67
Applications web riches (SPA)Applications web riches (SPA)
● “une seule page” chargée pour l'utilisateur.
● Des zones des page sont modifiées à la volée en fonction des
actions de l'utilisateur.
● Le JS traite les requêtes, reconstruit le html correspondant et
recharge la zone de la page.
● Le client devient le « principal » et le serveur « l'accessoire ».
● Répartition des rôles : AVANT (cas extrême)
● Serveur : gestion de la session utilisateur (état), traitement des
requêtes, mise à jour du jeu de données, renvoi des données
désirées, construction de la page de présentation des données.
● Client : validation de saisie, interprétation des pages envoyées par
le HTML, envoi des requêtes.
● Répartition des rôles : APRÈS (cas extrême)
● Serveur : opérations sur les données.
● Client : tout le reste.
8. 8 / 67
Applications web riches (SPA)Applications web riches (SPA)
Applications classiques SPA
Client
GET /some/page
Serveur
Renvoie une page HTML
Client
GET /api/some/resource
Serveur
Renvoie des données, en JSON
9. 9 / 67
Applications web riches (SPA)Applications web riches (SPA)
● Intérêts
● Fournir des applications web plus agréables à utiliser : plus
rapides, plus faciles à utiliser
● Capitaliser les développements serveur. les SOA (ou WEBOA)
permettent de ré-utiliser les API dans d'autres contextes :
applications natives, B2B, internes.
● Fournir des applications web apportant une grande valeur
ajoutée fonctionnelle
10. 10 / 67
Les conséquences techniques (SPA)Les conséquences techniques (SPA)
● Plus de gestion d'état côté serveur
● Le client doit assurer la gestion de la session utilisateur
(problématiques de sécurité accrues – attaques XSS).
● Déport de tout le traitement côté client
● Enjeu de performances : on gagne en bande passante, mais on est
soumis à la puissance de la machine de l'utilisateur.
● Problématiques spécifiques sur la gestion des données
● Sécurité : assurer la protection des données pendant la transmission
et le stockage.
● Performances : envoyer uniquement les données nécessaires, sous la
forme la plus légère et lisible possible.
● Intégrité : valider les saisies côté client.
● Les formats de serialisation : XML et JSON.
11. 11 / 67
AuthentificationAuthentification
● Le serveur est responsable de valider l'authentification et les
droits
● Ne jamais faire confiance aux données entrantes des requêtes
● Le client peut gérer les autorisations, mais c'est en dernier lieu
le serveur qui autorise, ou pas, l'action
● 2 pratiques couramment rencontrées :
● Fonctionner en mode connecté. 3 phases : login (cookie de
session), requête(s), logout (effacement du cookie de session)
● Fonctionner en mode déconnecté. A chaque requête, le client
renvoie l'intégralité des informations d'authentification
12. 12 / 67
Gestion des erreursGestion des erreurs
● L'utilisateur ne reçoit pas «de page d'erreur »
● La soumission d'une requête est forcément asynchrone, sous
peine de bloquer totalement le navigateur. On trouve deux
pratiques principales pour répercuter à l'utilisateur une erreur
apparue sur le serveur :
● Interface bloquante
On bloque l'interface (le formulaire ainsi que les liens de navigation)
le temps de recevoir du serveur le retour sur l’exécution de la
demande
● Interface à compensation de latence
On ne bloque pas l'interface, et on agit comme si le serveur avait
déjà répondu que la demande a été traitée avec succès. Dans le cas
d'une erreur, on patche le rendu et on indique à l'utilisateur l'erreur
de manière proéminente.
13. 13 / 67
Communication client/serveurCommunication client/serveur
● Le protocole de fait des applications SPA est REST
● L'URL pointe une ressource, la méthode détermine l'action à effectuer
● Le corps de la requête contient les données que le client communique
au serveur
● Le code réponse HTTP permet au client de déterminer la réussite de
l’exécution d'une requête.
● Le corps de la réponse contient les données que le serveur
communique au client.
14. 14 / 67
Communication client/serveurCommunication client/serveur
● Le langage de communication de fait des applications SPA est
JSON
● Langage extrêmement simple, facilement lisible par un humain
● Disponible immédiatement sous forme d'objet Javascript
● Parseurs et serialiseurs disponibles dans tous les langages de
programmation
15. 15 / 67
Communication client/serveurCommunication client/serveur
● Comparaison XML / JSON
JSON XML
Points forts
- Simplicité
- Disponibilité immédiate sous
forme d'objets dans le
navigateur
- Lisibilité
- Supporte des structures de
données complexes
- validateurs standards (DTD)
Points faibles
- Pas de structure de données
personnalisées
- Pas de système de validation
standard
- verbosité
- interprétation des données
dans le langage de
programmation natif
16. 16 / 67
AccessibilitéAccessibilité
● WAI ARIA (Accessible Rich Internet Application)
● Norme datant de 2010, encore en évolution (est en état
« proposed recommandation »)
● Adresse les problématiques d'accessibilité sur le contenu des
pages web, et sur le rafraîchissement d'une partie de ces pages
● Adresse les problématiques suivantes :
● Navigation au clavier
● Description des éléments
● État et propriétés des éléments
● Zones mises à jour dans une page
17. 17 / 67
Sécurité : serveurSécurité : serveur
● Mêmes règles que pour le développement classique
● Sécuriser autant que possible de flux de données (SSL,
certificats)
● Assainir et valider les données entrantes
18. 18 / 67
Sécurité : clientSécurité : client
● Attaques XSS (cross site scripting)
● L'objectif de l'attaquant est d'utiliser les trous dans
l'assainissement des données avant affichage afin d’exécuter
du code malveillant dans le navigateur des victimes.
● La stratégie la plus couramment employée est d'assainir les
données affichées dans le navigateur. La plupart des framework
Javascript assainissent systématiquement les données avant de
les afficher : un développeur voulant inclure dans la page HTML
des données non assainies doit par conséquent utiliser une
fonctionnalité spécifique du framework.
● Il est aussi possible d'assainir les données lorsqu'elles sont
traitées par le serveur.
Plusieurs librairies existent pour se faire, nous citerons par
exemple pour le langage Java les librairies de l'OWASP :
● https://www.owasp.org/index.php/Category:OWASP_AntiSamy_Project
● https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project
19. 19 / 67
Sécurité : clientSécurité : client
● Attaques CRSF (Cross Site Resource Forgery)
● L'objectif de l'attaquant est d'utiliser la persistance des sessions
dans un navigateur, afin que lorsque l'utilisateur se rend sur un
site malveillant, ce dernier initie des connexions au site visé,
par le biais du navigateur de la victime.
● La parade conseillée est d'utiliser le « Synchronizer Token
Pattern ». Le principe est d'inclure un jeton dans le formulaire à
soumettre, et le même jeton dans un cookie. C'est le serveur
qui a la responsabilité de créer ces jetons et de les vérifier
ensuite.
● Des librairies existent dans l'ensemble des langages afin
d’implémenter ce pattern. Nous retenons par exemple le projet
CRSFGuard de l'OWASP :
● https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Proj
ect
●
21. 21 / 67
Framework Javascript : composantsFramework Javascript : composants
● Composants indispensables
● Architecture MVC ou MVVM
● Routing
● Composants
● Loose coupling
● Two way data binding
● Injection de dépendances
● Cadre de tests
● Définition
● Un framework Javascript est une librairie apportant un
cadre pour le développement d'applications web riches.
22. 22 / 67
Caractéristiques des FrameworkCaractéristiques des Framework
● Databinding
● Le viewmodel s'occupe à la fois de la reception et de l'envoi des
données à la vue. Les différents composants d'une application
(model, vue) sont donc indépendants et peuvent évoluer de
façon indépendante.
view
view
viewModel
viewModel
Model
action
Data
binding
Data
binding
changes
notifies
notifies
23. 23 / 67
● Routing
● Capacité d'un framework d'indéxer une vue à une URL
spécifique et de permettre à cette URL d'évoluer avec e
changement de l'état de l'application
● Injection de dépendances
● Capacité du framework de charger automatiquement des
modules utilisés par l'application
● Loose coupling (couplage « lache »)
● Dépendance des composants implicatifs « minimale » les uns
envers les autres
Caractéristiques des FrameworkCaractéristiques des Framework
24. 24 / 67
Les principaux framework « front »Les principaux framework « front »
Date de naissance Licence Pilotage Librairies
complémentaires
Difficulté
2011 MIT Communautaire. Open
Source
Handlebars
jQuery
complexe
Date de naissance Licence Pilotage Librairies
complémentaires
Difficulté
2009 MIT Communautaire. Open
Source.
Google
underscore
jQuery
intermédiaire
Date de naissance Licence Pilotage Librairies
complémentaires
Difficulté
2013 BSD Communautaire. Open
Source.
Facebook
Facile
React n'est pas un
Framework MVVM
mais correspond à la
vue
26. 26 / 67
Support du Touch avec AngularJSSupport du Touch avec AngularJS
Le framework AngularJS fournit
un module ng-touch qui permet
de gérer les actions de base
des périphériques tactiles:
● Le tap
● Le swipe
Si l'application nécessite la gestion
d'intéractions plus complexes,
LINAGORA recommande interactJS,
qui prend en charge notamment:
● Le pinch-to-zoom
● Les rotations
28. 28 / 67
Contourner les limites traditionnelles du CSSContourner les limites traditionnelles du CSS
● Le CSS : langage puissant mais laborieux
● Langage totalement plat de description de la mise en forme
applicable à un élément.
● >>> Possibilité de réutilisation limitée.
● >>> Complexité d'appréciation du rendu final.
● La solution : les moteurs de génération dynamique de CSS
● Écrire son CSS en y intégrant la logique de conception.
● Faciliter la création et la maintenance d'une mise en page
cohérente et uniforme.
● Comment ça marche ?
● On écrit les styles dans un langage dédié permettant d'exploiter
héritages dynamiques et conditionnels, ainsi que des variables.
● Les styles sont ensuite passés dans une moulinette pour générer
le css “plat”.
29. 29 / 67
Concrètement, ça donne quoi ?Concrètement, ça donne quoi ?
Cas d'usage : usage des couleurs officielles
On utilise deux couleurs officielles à travers un site pour
tout l'habillage : #844F91, #FC7820.
CSS classique
h1, h2, h3, h4, h5 { color: #844F91; }
a { color: #FC7820; }
.button { color: #FV7820; }
etc...
Bénéfices
● Un endroit à modifier pour répercuter un changement de
charte graphique (variabilisation des CSS).
● Possibilité de donner des noms utiles.
● Éviter les erreurs de saisie de code couleur.
Écriture LESS
@color-primary: #844F91;
@color-secondary: #FC7820;
h1, h2, h3, h4, h5 { color: @color-primary ; }
a { color: @color-secondary; }
.button { color: @color-secondary; }
etc...
30. 30 / 67
Les fonctionnalités des langages de preprocessLes fonctionnalités des langages de preprocess
● Fonctionnalités répandues
● Support des variables.
● Réutilisation de classes (mixin).
● Rédaction de styles finement ciblés par imbrication.
● Fonctionnalités spécifiques selon l'outil
● Support de boucles de style.
● Fonctionnalités de traitement d'image (saturation,
arithmétique sur une couleur RGB etc).
● Extensions pour rajouter des fonctionnalités.
31. 31 / 67
Analyse critique des langages de preprocessAnalyse critique des langages de preprocess
● Avantages
● Code plus lisible et compréhensible.
● Facilité de maintenance et d'évolution (ex changement de
couleurs).
● Inconvénients
● Requiert un minimum d'apprentissage.
● Rigueur dans l'exploitation des imbrications.
● Librairies externes requises pour générer le CSS / intégrer le
support du Less à un CMS.
32. 32 / 67
Les moteurs disponiblesLes moteurs disponibles
LESS
● Préprocesseur en Javascript.
● Utilisable “à la volée” ou au préalable.
● Intégrable pratiquement partout.
● Toutes les fonctionnalités essentielles plus traitements de
couleurs et gestion de boucles.
SASS
● Écrit en Ruby.
● Un des pionniers du préprocess CSS.
● Propose deux styles d'écriture, dont un plus proche du
CSS classique.
CSS-Crush
● Écrit en PHP.
● Le plus facile à intégrer à de nombreux projets.
● Dispose de toutes les fonctionnalités essentielles.
Google Closure Stylesheets
● Écrit en Java.
● Fonctions d'arithmétique et de traitement de couleurs.
● Autotests basiques
● Renommage dynamique de classes CSS.
33. 33 / 67
Ressources d'approfondissementRessources d'approfondissement
● LESS
● Site officiel : http://lesscss.org
● Exemples d'utilisations efficaces de LESS :
https://codemyviews.com/blog/10-less-css-examples-you-should-
steal-for-your-projects
● Comparaison de moteurs de preprocess
● https://blog.logentries.com/2014/10/which-css-preprocessor-sh
ould-you-choose/ (2014)
● http://www.slant.co/topics/217/~css-preprocessors-postprocess
ors (2015)
34. 34 / 67
Objectif des générateurs de HTML : simplifier la conception etObjectif des générateurs de HTML : simplifier la conception et
la maintenancela maintenance
● Même principe que pour les préprocesseurs CSS
● “Coder” sa page HTML en utilisant de la logique de génération.
● Simplifier l'écriture de la page (éviter la lourdeur des balises à
fermer).
● Réutiliser autant que possible le même code.
● Même fonctionnement
● On écrit le code dans un langage spécifique, plus ou moins
proche du HTML...
● Puis le moteur afférent génère le HTML “final”.
36. 36 / 67
Material Design : l'art d'être plat à bon escientMaterial Design : l'art d'être plat à bon escient
● Publié par Google pour les développeurs Android
● Ne renie pas les effets “3D”...
● Mais les conceptualise et les intègre au Flat...
● En pensant également les interactions “au toucher”
● >>> Empilements et successions de feuilles de papier
37. 37 / 67
Material Design : les idées essentiellesMaterial Design : les idées essentielles
● Représenter les différentes régions dans une disposition en grille
● Représenter l'empilement avec les ombres (lien de parenté entre
éléments, importance relative de l'élément, interactivité)
● Créer des interactions représentées par des mouvements
● Utiliser des mouvements donnant du sens
● Indiquer visuellement à l'utilisateur la prise en compte de son
mouvement
● Ne jamais faire déborder l'interaction d'une “feuille” à l'autre.
● Respecter des limites “physiques” s'agissant des effets visuels entre
les “feuilles”.
● Limiter des transformations de forme à un même plan.
Toutes les recommandations
https://www.google.com/design/spec/material-design/introduction.html
38. 38 / 67
Material Design : dans la pratiqueMaterial Design : dans la pratique
● Pas d'obligation d'adhérer à l'ensemble des recommandations Google
● Concept ne convient pas à tous les cas d'usages...
● On ne peut pas empiler indéfiniment sous peine de perdre en lisibilité.
● Les animations peuvent aussi bien servir que distraire l'utilisateur.
● Les recommandations pour le “mouvement” sont avant tout pensées pour
le tactile.
● Ce qu'il faut en retenir
● Éviter des animations ou dispositions qui seraient intuitivement impossibles
avec des feuilles de métal.
● Exploiter les ombres pour indiquer l'élévation relative.
● Garder dans la mesure du possible les enfants “dans” la surface des
parents, faire évoluer les enfants “tous ensembles”.
● Jouer sur les niveaux pour hiérarchiser les contenus ou marquer une
interaction utilisateur (ex presser bouton).
● On ne peut pas empiler indéfiniment.
● Les animations peuvent aussi bien servir que distraire l'utilisateur.
Exemples : http://www.materialup.com/
39. 39 / 67
Les sept commandements de la conception de siteLes sept commandements de la conception de site
1. Les visiteurs sont là pour répondre à LEURS besoins.
2. Quiconque doit comprendre de quoi parle un site en 4s.
3. Ergonomie > Style (contraste, repères, menus, légèreté)
4. Simplicité et rapidité = fidélité (perfs, actions user).
5. Le site ne fait pas tout (processus, suivi).
6. Efficacité du backend = longévité du site.
7. Contenu > design.
40. 40 / 67
Pour aller plus loinPour aller plus loin
● Les pires erreurs de conception de site (EN)
● http://www.webpagesthatsuck.com/biggest-mistakes-in-web-de
sign-1995-2015.html
● Intégrer sa marque à une mise en page Material Design
● https://design.google.com/articles/expressing-brand-in-material
/
● Discussions autour du Material Design & Flat Design
● https://xhtmlized.com/blog/why-even-google-sometimes-makes-
bad-ui/
● http://blog.creative-tim.com/web-design/google-fails-implement
ing-material-design/
● https://medium.com/tech-in-asia/material-design-why-the-floa
ting-action-button-is-bad-ux-design-acd5b32c5ef#.tx1poi4m2
● http://ux.stackexchange.com/questions/81965/what-are-the-dis
advantages-of-material-design
● http://www.enterpriseux.co/how-flat-design-uses-psychology-to-tr
ick-us-into-believing-its-better/
41. 41 / 67
RessourcesRessources
● Centre d'outillage et de ressources Google
● https://design.google.com/resources/
● Gestion des couleurs
● http://www.w3schools.com/tags/ref_colorpicker.asp
● https://color.adobe.com/create/color-wheel/
● Gestion des fontes
● http://fontello.com/
● http://www.fontsquirrel.com/
● http://fortawesome.github.io/Font-Awesome/
● Respect des standards
● https://validator.w3.org/
● https://validator.w3.org/mobile/
● http://achecker.ca/checker/index.php
42. 42 / 67
Frameworks CSSFrameworks CSS
● Pour les applications intranet / extranet : Framework Material
Design
● Couleurs vives pour maximiser le contraste et limiter la
pollution visuelle
● Unités d'informations sous forme de cartes (widgets)
● Ombres portées générées en temps reel pour donner de la
profondeur
● Animations et transitions poussées pour donner du sens à des
actions
● Des mécanismes automatiques pour la gestion de l'ergonomie
et du responsive design
● ….
43. 43 / 67
Angular MaterialAngular Material
● https://material.angularjs.org : implémentation du material
design sous Angularjs.
45. 45 / 67
Angular MaterialAngular Material
● Layouts
● Layout basé sur Flexbox
(http://www.w3.org/TR/css3-flexbox/)
Mise en page qui fournit une
disposition des éléments de la page
de sorte que ceux-ci possèdent un
comportement prévisible lorsque
l'agencement de la page doit
s'adapter en fonction des tailles
d'écrans et des différents appareils.
Utilisés dans de multiples cas, le
modèle de flexible box offre une
amélioration au modèle block dans
lequel les flottements (float) ne sont
pas utilisés, ni la fusion des marges
du container flex et les marges de
ses éléments.
46. 46 / 67
Angular UIAngular UI
● Bibliothèque de composants (projet open source
complémentaire)
47. 47 / 67
Materialise cssMaterialise css
● http://demo.geekslabs.com/materialize/v2.1/layout02/form-la
youts.html
● ….des dizaines de frameworks CSS existent et s'utilisent plus
ou moins en fonction de la technologie « front » JS adoptés.
49. 49 / 67
NodeJSNodeJS
NodeJS :
● SingleThread
● Gestion de la concurrence
basée autour des
événements : utilisation
d'une boucle d'événement
FIFO (first in, first out) – les
callback sont traités dans
une file d'attente.
● Pas de « blocage » de
threads au niveau du
serveur, très bonne
performances
50. 50 / 67
Le framework ExpressLe framework Express
● Frameworks NodeJS
● Express (6 ans d'existence, 5000 commits)
● Gestion du Routing
● Moteur de template : Jade, Haml, EJS,...
● Gestion des sessions (cookies, store in memory/redis...)
● Très bonne documentation, nombreuses extensions, communauté
importante
● Hapi (3 ans d'existence, 3500 commits) : Configuration
importante VS le code.
Métrique Express.js Hapi.js
Github stars 17628 3857
Contributors 171 112
Watchers 1120 302
Package that depends on Environ 4560 Environ 120
Download last month 2 108 987 115 408
51. 51 / 67
Bibliotheques complémentaires – ex : authentificationBibliotheques complémentaires – ex : authentification
● Middleware d'authentification pour NodeJS
● SSO avec OpenID ou Oauth
● Permet de mettre en place différentes stratégies
d'authentification.
● Compatible avec différents providers existants
58. 58 / 67
Integrated Development EnvironmentIntegrated Development Environment
Atom ( https://atom.io/ )
Open Source
Origine: Github
basé sur le framework ElectronJS
Sublime Text ( http://www.sublimetext.com/ )
Licence payante
Origine: privée (Sublime HQ)
WebStorm ( https://www.jetbrains.com/webstorm/ )
Licence payante
Origine: privée (JetBrains)
Basé sur le framework IntelliJ
59. 59 / 67
Integrated Development EnvironmentIntegrated Development Environment
Atom ( https://atom.io/ )
Open Source
Origine: Github
basé sur le framework ElectronJS
Avantages:
- très rapide
- énormément de plugins
- communauté dynamique
60. 60 / 67
Integrated Development EnvironmentIntegrated Development Environment
Sublime Text ( http://www.sublimetext.com/ )
License payante
Origine: Sublime HQ
Avantages:
- très rapide
- énormément de plugins
- réputé chez les développeurs web
61. 61 / 67
Integrated Development EnvironmentIntegrated Development Environment
WebStorm ( https://www.jetbrains.com/webstorm/ )
License payante
Origine: Sublime HQ
Avantages:
- pleins de fonctionnalités
- auto-complétion
- même interface que IntelliJ
62. 62 / 67
JS stack: Bower & NPMJS stack: Bower & NPM
Bower (https://bower.io/) est un
package manager pour les librairies
web (à charger dans les navigateurs).
Bower supporte les versions,
dépendances, et les mises à jour.
La publication de nouveaux paquets
dans le dépot bower est complètement
gratuite.
Bower embarque un système de
resolvers évolutif, permettant
d'héberger des modules sur des
dépots privés.
NPM (https://npmjs.com/) comme Node
Package Manager, est le gestionnaire de paquet
des modules Node.js. Il est le plus grand dépot
de package connu, loin devant debian ou encore
maven.
NPM supporte les versions, dépendances, et les
mises à jour.
La publication de nouveaux paquets dans le
dépot bower est complètement gratuite.
NPM permet de faire pointer des résulutions de
modules sur des dépots GIT privés.
# bower install jquery # npm install express
63. 63 / 67
JS stack: assertion libraryJS stack: assertion library
Il existe un certain nombre de librairies d'assertion Javascript. Nous
présentons ici Chai, qui est utilisé à LINAGORA et qui a la
particularité d'avoir un certain nombre de modules communautaires.
Chai permet au développeur de choisir la manière dont il veut
exprimer ces tests: Test Driven Development (assertion) ou
Behaviour Driven Development (expect). Voici quelques exemples :
assert(false, 'this will fail');
assert.lengthOf([], 3, 'this array is
not 3 items long');
assert.match('hello', /salut/, 'regexp
failed');
expect(false).to.be.true;
expect([]).to.have.length(3);
expect('hello').to.match(/salut/);
64. 64 / 67
JS stack: test skeleton libraryJS stack: test skeleton library
Il existe aussi, pour les squelettes de test javascript, une offre
variée. Cependant, mocha est largement reconnu comme étant très
puissant, et pourtant assez simple.
describe('My test', function(){
it('should succeed', function() {
expect(true).to.be.false;
});
});
describe('My test', function(){
it('is async', function(done) {
doAsync(function(response) {
expect(response).to.be.ok;
done();
});
});
});
describe('My test', function(){
before(function() {
// setup mocks
});
it('do things', function() {
...
});
after(function() {
// clean up the room
});
});
Test de code asynchroneTest basique
Préparation et actions post-test
65. 65 / 67
JS stack: karmaJS stack: karma
Le rôle de karma est de permettre de lancer des tests dans le navigateur.
Karma se charge de créer l'environnement du navigateur (page web de base +
serveur HTTP), de lancer les tests, et de récupérer leur sortie.
Karma permet de lancer des tests sur
un navigateur “webkit” headless
(PhantomJS), un navigateur Gecko
headless (SlimerJS), mozilla Firefox
et Google Chrome, Internet Explorer,
Safari, Opera. Il permet aussi de se
brancher sur des services de tests
cloud du type Sauce Labs.
Karma est compatible avec les outils
de couverture de code JavaScript.
66. 66 / 67
JS stack: gruntJS stack: grunt
Grunt est la “colle” qui permet de définir puis lancer les différentes taches de
développement.
Le processus de développement JavaScript demande un
certain nombre de taches:
● Lancer le serveur en mode développement
● Lancer les linters
● Lancer les tests frontend
● Lancer les tests backend
● Lancer tous les tests
● ...
Grunt est un lanceur de taches, permettant d'automatiser les
développements.
67. Merci de votre attentionMerci de votre attention
LINAGORA – Siège social
80, rue Roque de Fillol
92800 PUTEAUX
FRANCE
Tél. : +33 (0)1 46 96 63 63
Fax : +33 (0)1 46 96 63 64
Info : info@linagora.com
Web : www.linagora.com