Bonjour je m'appelle Jean-Laurent De Morlhon, je suis directeur technique chez Xebia et depuis 15 ans je fais du logiciel. Voila essentiellement ce que je peux je dire.
Je ne suis pas ça de manière précise, mais il est vrai que ça bouge beaucoup. HTML5 une norme qui est faite de plein de petits morceaux qui sont à des degrés de maturité différents. Il y en a certain qui sont prêts, ou qui sont en produit et que l'on peut utiliser aujourd'hui. En revanche, d'autres ne le sont pas du tout. Mais c'est une norme qui évolue dans le temps. Maintenant, moi je suis plus pragmatique. Je regarde plus ce qu'il se passe sur le terrain. J'utilise juste les éléments dans HTML5 que l'on peut utiliser et c'est plutôt ça qui m’intéresse.
3. InfoQ : Que penses-tu de la fragmentation des moteurs de rendu et des différentes implémentations ?
La différence entre les navigateurs tend à se réduire, puisque la plupart des navigateurs commencent à utiliser le même moteur de rendu. Cela va être donc de plus en plus simple. Par contre Google a annoncé récemment qu'ils allaient justement partir sur leur propre implémentation de moteur de rendu. Il y aura donc toujours des différences entre les navigateurs, et je pense que c'est une bonne chose. Car la compétition restera toujours active et on ne se retrouvera pas enfermé avec le même navigateur et aucune innovation à l'intérieur. Mais malheureusement pour nous développeurs qui créons des applications web cela nous demandera un peu plus de rigueur.
Le talk que j'ai fait aujourd'hui était un peu particulier. J'ai testé une façon d'écrire les tests en utilisant Cucumber. C'est un framework de test qui permet de faire du Behavior Driven Developpement. Cela consiste à exprimer des tests sous une forme textuelle, qui pilotent directement un navigateur "headless". Un navigateur headless est un navigateur sans tête, qui n'affiche rien, et sert uniquement à tester des applications web. L'idée c'était de montrer une méthode simple pour tester les applications web qui utilisent beaucoup de Javascript et d'échanger avec le public afin qu'ils me donnent leur feedback.
5. InfoQ : Quels sont aujourd'hui les principaux framework de test ?
Aujourd'hui nous avons utilisé Zombie en conjonction à Cucumber dans le panorama des outils de tests modernes. Il y a aussi Karma, un lanceur de test très populaire, puisqu'il fonctionne très bien avec Angular JS, un framework poussé par Google qui a le vent en poupe. Il y a aussi Phantom JS, un navigateur sans tête qui permet d'avoir du binding pour effectuer des tests sur cette partie. Et enfin Casper JS développé par un français, qui nous met à disposition une API un peu plus fluide. Dans tout les cas pour les tests d'interfaces nous avons ces outils de manière prépondérante à notre disposition.
6. InfoQ : Est-ce qu'il existe des tests pour mocker la partie serveur ?
Alors est-ce qu'il existe des outils pour mocker la partie serveur ? Oui, en général sur les applications que je rencontre j'ai souvent des backends écrits en Java, je vais donc utiliser des outils de mock classiques, dont EasyMock et Mockito. Exécuter des tests dans un navigateur est plus difficile. Car Il faut pouvoir transformer la configuration pour dire, je veux être dans un état de Mock, ou je ne veux pas être dans un état de Mock. Et créer des tests classiques côté Javascript peut être problématique, puisse qu'il faut être capable de concevoir des outils et faire quelques petites bidouilles. Mais il existe un framework qui règle en partie ce problème. Il s'appelle FluentLenium et permet d'écrire des tests en Java. Il est ainsi plus facile d'injecter la configuration de Mock. C'est un bon cas d'utilisation pour ce type d'outil.
Je ne suis pas un expert de la balise vidéo. Tout ce que je sais, c'est que Phantom JS, un des navigateur sans tête, la supporte puisqu'il utilise un moteur webkit. Typiquement il va respecter l'espace dans le navigateur, mais il ne va pas l'afficher. Je n'ai pas plus d'expérience particulière sur cette balise, puisque dans le monde de la finance ou de l'informatique de gestion on a rarement besoin de ce type de balise. Je ne peux donc vous en dire plus.
Je pense qu'il y a beaucoup de termes et beaucoup d'acronymes parce que c'est un monde qui est en train de se définir et d'avancer. Ils ont été créés par des techniciens, des programmeurs, et parfois par des Agilistes. Il y a donc pas mal d'acronymes qui tournent. Est-qu'on en a vraiment besoin ? Je pense que s'ils existent c'est qu'ils ont leurs utilité dans chacun de ces domaines. Est-ce qu'on a besoin de tous ? Il y a les tests unitaires de base, les tests dit de service, de fonction qui sont au centre, et les tests d'interface. Effectivement on peut mettre différents types d'acronymes, chacun ont leur signification. Mais c'est vrai que c'est un peu ardu et ce sont des techniques qui demandent beaucoup d'assimilations. Par exemple c'est un peu compliqué de commencer à faire du BDD ou TDD, si vous lisez juste la théorie. C'est une chose que l'on découvre en pratiquant. Mais effectivement c'est une jungle assez vaste.
9. InfoQ : Selon toi si je n'ai pas une couverture de test à 100 % est-ce mal ?
Rire. Non ce n'est pas mal. Je pense que la meilleure façon d'avoir une bonne couverture de test, c'est de na pas s'en préoccuper car ça veut dire qu'elle est forcément bonne. Je pense d'ailleurs que le 100% est parfois très difficile à obtenir. Il faut savoir jauger le temps d'écriture des tests et la couverture souhaitée. C'est souvent un idéal rarement atteint, mais on peut y arriver. C'est peut-être nécessaire sur certaines parties du logiciel, les parties très très critiques, d'essayer de vraiment tout tester. On va notamment regarder, sur du code Java un certain type d’exception qui ne sont pas attrapées et induisent un problème majeur. Car elles remontent tout en haut de la stack et font sauter toute l'application. Mais est-ce que ça vaut vraiment le coup de tester tous ces cas là ? Je n'en suis pas sûr, je pense qu'il faut avoir aussi un peu de pragmatisme. J'aime bien quand les équipes se concentrent sur l'essentiel et de temps en temps je jette un coup d’œil pour voir si on est dans les clous. Souvent ces équipes sont autour de 70-80% de code couvert ce qui très très bien et à mon avis largement suffisant.