A no bug's life

J’ai découvert il y a peu l’excellente commande _npm outdated _qui permet de vérifier si on est à jour de ces dépendances, et de visualiser le gap.

Je trouve ça bien plus utile que de faire un update sauvage sans vérifier que l’on ne change pas de version majeure avec breaking change : j’aime m’assurer que mon code tournera encore après une mise à jour de ces dépendances, que voulez-vous... ;)

Et vu que bower ne proposait pas d’équivalent à cette commande, je me suis lancé et en quelques heures c’était plié et j’avais codé et publié bower-outdated (ça m’aurait pris moins de temps si ça n’avait pas été mon premier projet node global :p)

Ou pourquoi la revue de code est une étape absolument nécessaire et comment la mettre en place

A quoi sert vraiment une revue de code ?

Si l’on croit la plupart des articles sur le sujet, la revue de code est sensé “permettre de détecter les défauts dans le processus de développement le plus en amont possible” et donc limiter le risque de bug.

Concrètement, je trouve que c’est un résumé réducteur, j’y vois plutôt ces deux objectifs : - Vérifier qu’une tâche développée ne contient pas d’erreur de logique, qu’elle est relativement optimale (ou en tout cas pas inutilement complexe) et que tous les cas d’utilisation ont été implémentés - S’assurer que le code sera compréhensif et maintenable (donc correctement écrit ou documenté lorsque nécessaire, avec des variables et méthodes aux noms intelligibles, ect)

Pour le premier point, les tests unitaires sont censés déjà remplir cette fonction; il faut bien cependant que quelqu’un vérifie, a minima :

que les tests sont bien écrit

qu’ils ont du sens

qu’ils ne font pas que bêtement appeler du code pour augmenter la couverture / que les assertions sont pertinentes

qu’ils prennent en compte les cas aux limites, etc.

Pour le second point, c’est déjà plus relatif… mais la finalité est de comprendre ce que fait le code le plus rapidement possible, sans avoir à demander à celui qui l’a écrit (auquel cas il faut, de facto, le notifier pendant la revue)

Et bien évidement le code doit être sans redondance, le plus homogène possible avec le reste de l’application (pas deux termes différents pour parler de la même chose) et doit être refactoré si besoin, selon le temps disponible pour cela. De plus, en dehors de ces objectifs, la relecture de son code par un tiers reste évidement un excellent moyen de vérifier que l’on a pas commis des erreurs d'inattention basique ; et c’est aussi le meilleur accompagnement à donner à quelqu’un qui arrive sur un projet pour qu’il monte en compétence ! C’est également une formidable aide à la cohésion d’équipe, surtout entre développeurs ne se connaissant pas / n’ayant pas travaillé ensemble et un outil d’amélioration continue !

Comment faire du code review

Avec des outils comme gitHub, gitLab ou encore bitBucket, il est très simple de mettre en place des demandes de relectures de code avant validation (pull request chez gitHub & bitBucket), plus besoin donc d’aller lire le code de quelqu’un par dessus son épaule et surtout, les ajouts, suppressions et modifications sont affichées de manière intelligible !

Pour aller avec l’outillage, il faut la méthodologie qui sied bien : avec git, le plus simple reste sans doute de faire du git flow, et de ne merger les branches qu’à la validation du code review. La taille de l’équipe et son organisation importe également énormément ! La revue de code va prendre du temps et demander de la concentration pour être efficace, et même si, idéalement, tout le monde devrait relire le code des autres et l'approuver à l’unanimité, c’est bien souvent impossible au delà de 3 développeurs sur un projet… 2 relecteurs par demande semble être le meilleur compromis. Bien entendu, les revues de code doivent être faites dans un délai raisonnable après la publication d’une demande de relecture, et ne pas s’empiler (le stock, c’est le mal) Pour une revue de code plus efficace, il convient d’avoir un template contenant une checklist de point critiques à vérifier :

Si le développement implique du front, poster une capture d’écran

Si un ajout/modification de base est faite, la documentation doit être mise à jour

Avoir un lien vers le ticket de la tâche à réaliser (jira, trello, bugzilla, mantis...)

Ect...

Comment relire / proposer une amélioration ?

Avant de relire, il faut connaitre la description de la feature derrière le code, il est donc indispensable d’avoir un lien vers le ticket concerné. L’outil de revue de code doit permettre l’ajout de commentaire, c’est indispensable. Ceux-ci se doivent d’être le plus clair possible, sans quoi le développeur va perdre du temps à essayer de comprendre ce qui ne va pas; il ne faut donc pas hésiter en cas de doute à relire le code directement avec le développeur qui l’a initié, cela est parfois plus rapide et efficace que d’écrire des remarques incompréhensibles pour autrui. Basiquement, il faut, avec le besoin en tête, regarder les modifications de code et voir si on les comprend et si elles sembles pertinentes. En cas d’incompréhesion, faire un commentaire en proposant un autre nom / une autre façon de faire Si le code est clair mais qu’il pourrait être amélioré, proposer un code plus optimal, et si possible en exprimant le niveau de criticité (par exemple : si tu as le temps, fais ceci... versus ton code va générer des fuites mémoires vu les volumes attentdus, fais plutôt comme cela...)

Par la force des choses (une mission sur le sujet qui commence la semaine prochaine) j’ai été confronté de plein fouet à du code en coffee et... que ce fut rude !

Pour un novice, le code est tellement différent du JS qu’on peine à comprendre, mais après quelques temps on se rend compte déjà à quel point le code est plus compact, plus efficace qu’en JS. Il y a clairement une inspiration venant de python qui est bienvenue, permettant de s’affranchir des accolades notamment, mais aussi d’autres éléments redondant. Aucun besoin de librairie spécifique autre que le compilateur, donc compatible avec n’importe quel framework, coffee est surcouche propre et efficace, une supercouche à utiliser a priori sans modération.  On y trouve aussi des inspirations de ruby, que du bon vous dis-je !

J’ai fait un test en réécrivant un exercice de TDD en node avec du coffeescript, puis j’ai refondu une directive AngularJS sur laquelle je travaillais en coffee également. En moyenne, j’ai écrit 30% de lignes en moins qu’avec du JS, et le code est plus lisible (une fois habitué à la syntaxe à la syntaxe) Tous les éléments redondant au possible (les fonctions, les brackets... ) sont simplifiés syntaxiquement, et certains opérateurs sont rendus plus lisibles (is remplace ===, isnt remplace !==) La POO est également rendue bien plus élégante, en supprimant les appels à 'prototype' et en proposant une structure typique de classe et d’héritage. Enfin, l’opérateur génial qui devrait achever de convaincre les sceptiques : le ? Quelle galère que de devoir tester, lorsque l’on veut récupérer la valeur d’un object, dans un objet, que chaque élément existe... ex:  parent:   child:     value: 42

#ne retourne value que si parent existe, avec l’objet child, ect parent?.child?.value

En gros, c’est un raccourci pour tester !== undefined && !== null, combiné avec les autres éléments de syntaxe de coffee, on obtient un code très littéral (value = 5 unless previousValue?) qui, une fois compilé en js, est parfaitement rigoureux.

Ayant toujours un oeil sur le marché du travail, je remarque que php est encore énormément demandé, même dans des sociétés se targant d’être modernes et performantes...  pourtant ce langage a été crée par un homme qui n’aime pas développer (source : https://en.wikiquote.org/wiki/Rasmus_Lerdorf ) et en comprend pas les gens qui aiment cela... Pour ma part, ses réflexions m’ont éclairé sur ce langage sur lequel j’ai pourtant fait mes premières armes : il est simple d’approche, pratique pour les étudiants et les sites persos, mais jamais il ne devrait être utilisé dans un contexte professionnel sérieux. Et vu qu’aujourd’hui il a des concurrents tout aussi simple d’accès (voire plus) alors pourquoi existe-t-il encore ?

Tout d’abord, répaticulons ce qui ne va pas dans php :

La syntaxe object->attribute &  Object::constant Gros WTF déjà....deux formes différentes selon qu’on récupère l’attribut d’une instance d’objet ou une constante dans une classe objet... wow, pratique !  Et puis l’usage de 2 caractères à chaque fois, le pire étant la flèche, suffit personnellement à me faire vomir. La norme, c’est le point. Java, javascript, python, ect, utilisent le point comme notation objet car c’est simple, et ça se combien très bien avec un IDE et son auto-complétion. L’évolution de php n’a jamais été dans ce sens, et c’est une première abbération.

Les performances  Ma dernière expérience, en 2014, sur php 5 m’a fait constater une chose incroyable : php n’arrivait pas à désérialiser un JSON au delà d’une taille pourtant ridicule (quelques dizaines de Mo) et, pire que tout, ne générait aucun message d’erreur. Juste une énorme fuite mémoire... Je ne parle même pas des temps d’accès à une base de données... totu simplement inacceptable. Alors certes, php est de base un langage scripté et non compilé. Certes, il existe de façon de le “précompiler” pour le rendre visiblement plus performant. Mais cela ne retire pas les fuites mémoires, et java tout comme nodeJS sont bien plus performants à l’execution.

Obsolescence des fonctions intégrées. Nombre de fonctionnalités essentielles n’existent pas dans le coeur de php5, il faut passer par des librairies tierces. Or, en 2015, créer un webservice REST par exemple devrait pouvoir être natif dans un langage comme c’est le cas en java depuis java 6 par exemple, ou nativement en ruby & en nodeJS depusi toujours. Le problème vient peut être que php5 existe depuis bien trop longtemps et n’a pas beaucoup évolué, la communauté préférant justement l’ajout de framework (zend par exemple) pour palier à ce manque. Php6 étant sur le point de sortir, peut être changera-t-il enfin la donne ?

La gestion des dépendances (librairies tierces, modules...) Php a depuis peu “composer”, un système visiblement équivalent à la simplicité d’utilisation de npm (node) ou gem (ruby) Je n’ai pas eu l’occasion de le tester, et il est sans doute très bien de ce que je lit à ce sujet. Le seul défaut est qu’il arrive peut être un peu tard, car nombreux sont les développeurs ayant pris de mauvaise habitudes. Et ce système ne change pas le fait qu’il faut configurer également les modules php dans le serveur apache. Ce qui reste un gros défaut lié à la nature même du langage.

Les tests unitaires Php a bien évolué de ce coté, avec un framework PhpUnit très inspiré de java et son JUnit. Mais ce sont les développeurs qui n’ont pas encore pris l’habitude et surtout, depuis JUnit on a fait bien mieux je trouve. Des frameworks de test comme Mocha (node) proposent en effet une approche “BDD“ (Behavior-driven development) que l’on peut considérer comme une surcouche au TDD. Pour résumé, cela rend le test beaucoup plus lisible, et surtout permet d’associer une série de tests à une fonctionnalité, en écrivant noir sur blanc la règle fonctionnelle, et facilitant les interactions entre le chef de projet/coach agile, responsable QA et le client final. Ainsi donc, php n’est pas vraiment mauvais sur ce point, mais il est en retard par rapport à la concurence

Personnellement, je pense que des langages comme ruby ou nodeJS sont bien plus intéressant que php. je ne comparerais volontairement pas à Java car  les cas d’utilisation ne sont pas, à mon sens, comparable. (java est surtout à utiliser pour du traitement lourd de nombreuses données)

Mais alors, si la concurrence est meilleure pour faire du web, pourquoi les gens, les sociétés, utilisent encore php ?

Les CMS C’est pour moi LE gros point fort de php : de wordpress à Joomla (que j’ai pas mal pratiqué fut un temps) ce langage a permis l’arrivée de système de gestion de contenu aujourd’hui quasi-incontournables. Créer rapidement un site web en ne se concentrant que sur le design et plus sur les fonctionnalités, c’est une avancée indéniable.

Les solutions d’hébergement Un des points qui fait que beaucoup de personne faisait du php était qu’on trouvait beaucoup de solutions d’hébergement couplés php/mysql pour pas cher, oir egratuit (chez free.fr à ses débuts par exemple) Beaucoup d’hébergeurs payants se sont d’ailleurs spécialisés dans ces offres, refusant alors de s’ouvrir à d’autres technologies pour viter de prendre un risque (cela peut se comprendre, ne leur jettons pas la pierre)

npm c'est bien, mais pas assez... venant du monde java, j'ai été confronté à quelque chose d'assez inédit : la disparition soudaine d'un module, dépublié par son auteur du repo npm global. A ce moment là, je me suis dit : "mais ce n'est pas pro du tout ! Tous les projets utilisant ce module en tant que dépendance vont devenir inutilisables"... et je le pense encore, c'est un non-sens ! Déprécier oui, dépublier, non !

Cette expérience m’a fait réaliser que, clairement, npm ne vaut pas maven, ce n’est pas un repository fiable pour un projet professionnel souhaitant la perennité de ses dépendances externes, il faut absolument un proxy ! Mon client utilisant déjà un repository nexus pour maven que je lui avait installé (pour ses projets java), je me suis penché sur le plugin adapté... à part l’obligation de le recompiler localement, il fait le boulot parfaitement, et les explications fournies sur le github sont exhaustives

Ça faisait quelques temps que je voulais mettre à jour les jobs jenkins chez mon client IDCware, avec un truc simple mais vital : gérer les numéros de version partout, automatiquement ! Helas, jenkins n'a aucun module pour facilement récupérer ou mettre à jour un numéro de version dans un fichier... couplé avec maven tout se fait facilement, mais dès qu'on en sort... surtout avec node.js... c'est une autre histoire.. mais pas besoin d'inventer de nouveau plugin pour autant ! En fait, c'est tout simple... il suffit de passer par les commandes linux sed & awk. (commandes que je ne connaissais évidement pas avant cet exercice - on apprend tous les jours dans notre métier et c’est ça qui est bon ^^) Récupérer un numéro de version depuis un fichier package.json se fait donc ainsi : awk -F "," '/"version": "[0-9].[0-9].[0-9]"/ {print $1}' package.json | awk -F ":" '/"version": "[0-9].[0-9].[0-9]"/ {gsub(/"/,"",$2); print $2}' (sans doutes pas la version la plus optimale, mais ça fonctionne parfaitement !) Ensuite, il faut pouvoir intégrer le résultat de la commande dans une variable d'environnement jenkins... pour faire cela, j'ai pris le Environment Scrip Plugin - résultat :

j'ai maintenant ma variable d'environnement CURRENT_VERSION que je peux utiliser pour mes tags git : git tag -a -f -m 'Release Version: $CURRENT_VERSION\n Build Number: $BUILD_NUMBER\n Build Id: $BUILD_ID\n Git commit: $GIT_COMMIT' $CURRENT_VERSION et pour sonar : (..) sonar.projectVersion=$CURRENT_VERSION

Maintenant, une fois tagué par le job dédié, je veux incrémenter mon numéro de version et qu'il soit mis à jour dans tous les fichiers de conf... - j'ajoute un paramètre de type String à mon job de release (celui qui crée le tag) : NEXT_RELEASE_VERSION

Et je passe la commande suivante dans un shell - exemple pour le fichier de configuration node :

Une fois les bases d'angular en main, voilà comment j'ai refondu mon application: Basiquement, je crée un seul module et un premier contrôleur, principal.

J'y stocke, via le $rootScope, mes 'méthodes utilitaires' que j'utilisais dans le site : gestion des notifications internes (fenêtre colorées et animées, JQuery), gestion des cookies, reset des timeouts...

Je route mon utilisateur vers le formulaire de connexion au besoin, ect... Le modèle view/controller est vraiment très très simple à appréhender, quelque part je trouve que ça rappelle les bons cotés de GWT par exemple : du code isolé, facile à tester; des vues qui ne sont que des templates.

La mise en place du TDD n'est pas si facile, surtout avec le legacy JQuery, mais a minima je fais un test par controller (ne serait-ce que pour détecter facilement les erreurs bêtes). Les tests d'appels ajax sont tout simplement géniaux, chaque nouvel appel que j'implémente a droit à son mock, ça simplifie énormément le dev, et la prise en main n'est pas si longue (j'ai cependant l'habitude de mocha et de node..ça peut jouer:p)

Bref, il m'aura fallu une bonne semaine pour migrer l'existant, immédiatement suivi par de lourdes nouvelles fonctionnalités à implémenter... et angular m'a sauvé, mais non sans mal !

99% compatible avec JQuery : 

Quasiment tout l'existant du code JQuery qui composait l'application a pu être réutilisé quasiment tel quel. mine de rien, les approches n'étant pas les mêmes, ça peut quelque fois buguer, notamment dans les tests.. Rien de très grave dans l'absolu, même si ça peut prendre la tête sur certains cas xD En tout cas ça marche, alors il n'y a aucune raison urgente de modifier ce code, et ça fait plaisir !

Les directives: la logique dans les vues/templates Encore une solution très élégante, les directives sont des attributs html à ajouter aux différentes balises des vues, pour les lier à des éléments du scope du controller (aka le 'modèle' dans le discours de google) 

Outre le fait de juste lier un champ d'un formulaire à une variable, on peut itérer (avec des filtres et des tris au besoin), masquer, adapter la vue de manière très propre, gérer des cas conditionnels.. De fait, créer une liste de donnée alimentée par un appel ajax prend 5 minutes quand on prend l'habitude: il suffit de lier dans le template un attribut du scope à la liste déroulante, puis d'effectuer l'appel ajax en poussant les résultats vers ce même attribut. La liste déroulante se mettra à jour directement quand son 'modèle' sera chargé... c'est bluffant !

La gestion du 'pipe' est également excellente ! En ajoutant, à la directive d'itération, un 'pipe' (comme en linux !) on rajoute une condition à l'itération, par exemple filtrer les éléments avec un attribut null, ou faire un tri sur la collection selon un autre attribut... (qui peut lui même dépendre d'un autre élément de la vue... )  C'est puissant, élégant et relativement facile à lire, mais a priori, il faut tout de même en user avec parcimonie, à cause du 'moteur' d'Angular : c'est apparemment la fonctionnalité la plus coûteuse en terme de perf...

Penser à rafraîchir !

J'avoue ne pas avoir encore compris totalement la mécanique, mais il faut parfois user de la méthode $apply() sur un scope afin de forcer le rafraîchissement de la vue après avoir modifié certains attributs du scope, usés dans des "directives" ng-model ou ng-bind...

Mieux que les events : l'observeur !

La fonction scope.$watch(<attribut>) permet à un contrôleur de réagir dès qu'un objet est modifié, évitant d'avoir besoin de générer un event ! En fait, la modification de l'objet est déjà en soit un event implicite, il suffit de s'y abonner. Tout au plus faudra-t-il selon le cas appliquer la fonction scope.$apply() afin de "flusher" l'event.

Bémol : pas de "load on demand" natif ! Contrairement à JQuery, angular ne propose pas de chargement de librairie JS dynamiquement, ce qui permettrait d'alléger le poids des fichiers à télécharger au démarrage (juste vital en application mono-page de type RIA...)  En passant par le module 'route', on peut pallier à ce problème.... Pour le coup, au vu du modèle du framework, de son orientation 'convention over configuration' je suis très déçu que cette fonctionnalité ne soit pas dans le core, et qu'i faille ajouter les sources js de ses contrôleurs à la main... http://weblogs.asp.net/dwahlin/archive/2013/05/22/dynamically-loading-controllers-and-views-with-angularjs-and-requirejs.aspx http://blog.getelementsbyidea.com/load-a-module-on-demand-with-angularjs/   

Bonus : Un peu d'intégration Continue

Afin de mesurer les progrès à réaliser en terme de test, et pouvoir ultérieurement donner des objectifs à mes devs front-end, il me fallait calculer la couverture du code. (En node, j'utilise istanbul via jenkins puis sonar, j'entendais bien faire de même ^^) J'installe donc quelques extensions de karma :

-tests & rapport au format JUnit : npm install -g karma-junit-reporter -couverture par les tests : npm install -g  karma-coverage Configuration (dans karma.conf.js) :

reporters: ['progress','junit', 'coverage'],                  junitReporter : {       outputFile: 'test-results.xml' },          preprocessors: {       '**/app/js/*.js': ': ['coverage'] }, coverageReporter: {        type : 'lcov',        dir : 'coverage/' }

Envoi dans sonar depuis jenkins :

sonar.dynamicAnalysis=reuseReports

L’agilité ne permettant pas de passer beaucoup de temps à travailler sur la conception et la doc, il convient d’être le plus efficace possible. En node (et JS) le manque de typage des données impose une documentation la plus exhaustive possible, avec les structures d’objets attendus lorsque cela est nécessaire. (un simple json au final)

Vu que mes développeurs sont des fainéants, et c’est bien normal, faire de la doc ça les saoule… autant leur éviter de faire de la saisie en double, et à moi aussi. Vu qu’il y avait déjà dans le code des annotations façons javadoc, j’ai fouillé un peu dans les libs de génération de doc :

-> YUIdoc : trop orienté objet/API. Pas pour nous donc (et devoir annoter les noms de méthodes, bisarre…)

-> Doxx : a priori, parfait ! Le fait de garder le code source est un plus intéressant, vu que l’on ne publie pas une API. Excellent template par défaut, bien que la navigation pêche un peu, un regroupement par folder aurait pu être facile pourtant…

-> Dox-foundation : Dox se présentant comme un refactoring complet de dox-foundation, la curiosité m’a poussé à aller tester ce dernier :

PAF! En une ligne de commande, ma doc est générée, avec les fonctions groupées par fichier, et toujours la possibilité de voir le code source… inutile de chercher plus loin, ça me va, je passe à l’IC ! Publication automatisée de la doc :

Dans jenkins, j’ajoute une étape “execute shell script” à mon build, avec la commande “dox-foundation —source src —target docs -i test”.

Via le plugin “Publish HTML reports” j’associe la doc générée à une addesse permanente sur mon serveur.

J’ajoute le lien permanent de la doc, générée à chaque build, dans notre outil de doc interne (Confluence)

Maintenant que le coeur de la nouvelle version de notre logiciel, recodé en NodeJS, est suffisament avancé, il est largement temps de repenser notre IHM...

D'une base d'un immonde framework php, j'étais passé à un quasi pur jquery+bootstrap, et il est vrai que la structure ne me plaisait pas franchement,.. mais je pensais que c'était hélas le propre d'un site web : un mélange inharmonieux de js et de html, quasi intestable unitairement, ect...

Et j'entendais beaucoup parler d'angularJS.. a première vue, j'étais sceptique : trop 'magique', trop abstrait... et puis Zenika a eu la bonne idée d'organiser un workshop nocturne sur le sujet, afin de nous montrer POURQUOI ce framework est bon.

Angular est en fait un framework permettant de modulariser le fonctionnement d'un site web. Chaque élement html (composant) peut en effet être associé à un 'modèle'  (définition d'une structure de donnée) et d'un contrôleur (ensemble des méthodes, variables autour de ce composant) Ce contrôleur peut être testé tout à fait unitairement, c'est une des premières forces d'angular pour moi. De plus l'écriture des tests est la même que celle que nous utilisons déjà avec mocha, en nodeJS. Reposant sur un principe de "Convention over configuration" à la manière d'un ruby on rails, le gain de code à écrire semble en effet CONSIDERABLE (jusqu'à 10 fois moins) et en plus la syntaxe déclarative reste très lisible

Avant-propos : comment gérer proprement les dépendances JS ? J'en avais déjà entendu parler mais je n'avais pas encore testé l'outil - apriori - adéquat... Quitte à migrer sous angular, autant en profiter pour là encore reprendre une bonne pratique de node et maven.

J'installe donc bower (merci twitter encore une fois)

npm install -g bower

Bower est l'équivalent de npm pour les dépendences JS, même commandes, même facilité... j'édite donc un fichier .bowerrc à la racine de mon projet

{"directory": "lib/js","json": "bower.json"}

Et le ficher bower.json :

{

"name": "boardvisorGUI", "version": "0.3.3", "dependencies": {"jquery": "~2.1.0","bootstrap": "~3.1.1","jquery-ui": "~1.10.3","angular": "~1.2.13"} }

Note : je n'a pas rajouté manuellement l'attribut 'dependencies' , j'ai utilisé la commande "bower install <package>" avec l'option -save, à la racine de mon projet, afin que bower télécharge la lib et l'ajoute à la liste de mes dépendences dans le fichier de conf. Les éléments téléchargés sont ajoutés à git-ignore.

Migration en TDD vers Angular

Mon challenge va être de recoder, en TDD et bout par bout, l'existant de mon IHM en Angular. Non seulement je m'assurerais proprement d'avoir respecté mon contrat, mais en plus je poserais les bases de la structure à suivre pour la dev team.

1. Mise en place d'angular

Je définit tout d'abord l'application globale 

<html ng-app="boardvisorApp">

Et mon composant global

<body ng-controller="mainCtrl">

en ayant bien sûr ajouté angular, géré par bower :

<script src="./lib/js/angular/angular.min.js"></script>

et mon controlleur principal

<script src="app/js/mainController.js"></script>

Afin de tester la structure de test, je commence par un dummy test dans le code de app/js/mainController.js :

var boardvisorApp = angular.module('boardvisorApp', []);

boardvisorApp.controller('mainCtrl', mainCtrl);

function mainCtrl($scope) {

   $scope.init=false;

}

Et le failing test mainControllerTest.js :

describe('main Controller Tests', function() {

   beforeEach(module('boardvisorApp'));

   describe('mainCtrl', function() {

      it('init should be true', function() {          var scope = {}, ctrl = new mainCtrl(scope);          expect(scope.init).equal(true);       });    }); });

Maintenant, faisons tourner une première fois les TU.

2. Installation de Karma et lancement des tests

npm install -g karma npm install -g karma-mocha npm install -g karma-junit-reporter npm install -g karma-coverage npm install -g karma-firefox-launcher bower install expect -save karma init

Je choisis 'mocha' dans les options, choisi mon browser (firefox) et valide. Je reprend manuellement le fichier généré, karma.conf.js, et défini mes paths vers mes fichiers de sources et de test.

karma start

Chez IDCware, vu que nous utilsons JIRA pour le bugtracking, il nous a semblé assez logique de tester Stash, le repo GIT d'entreprise du même éditeur (le but n'est pas de faire de la pub pour le produit, testez par vous même si le coeur vous en dit :p)

Une fois le choix validé, nous avons donc migré au fur et à mesure nos repos GIT vers stash (en quelques commandes : clone --mirror / remote add stash / push -all ...) tout était migré, historique inclus. La puissance de git ne cessera de m'étonner :D

Là ou le bas blesse, c'est que l'authentification git pour Jenkins est un saccerdoce ! La doc parle bien de l'authentification par ssh (ce qui était notre configuration initiale) mais pas par http... -_-

Fort heureusement, une recherche pertinente et la solution fut trouvée : "netrc" - un simple fichier à créer dans le 'home' de l'utilisateur lançant jenkins. Avec notre version de stash (2.6.0) la notation proposée dans le lien ci-dessus ne fonctionne pas;, mais l'authentification est bien prise en compte lors d'une commande "git clone http://<server>:port/<git_repo>" (qui devient alors équivalente à "http://<mon_user>>@<server>:port/<git_repo>" avec le mot de passe directement renseigné. Seul petit hic cependant, même si cela n'est pas très grave pour une utilisation en interne, c'est que le mot de passe du fichier .netrc est en clair... 

Via @MrCafetux et le site androidfr.com j'apprends l'existence de ce que je qualifierais de "bizarrerie" : un portage de php pour développer des applications android...

Sans remettre en cause les compétences des gens à l'origine de cette initiative, il y a deux choses que je ne comprends pas : 

Pourquoi php ? C'est un langage à déprécier, qui a fait son temps mais n'a pas su/pu évoluer correctement... Rasmus Lerdorf lui-même a admis l'avoir créé en tant que simple outil pour ces petits tracas, que ses perfs étaient pas top, ect... Et dans le cas présent, le portage utilise une surcouche : le code php sera interprété par une autre appli ! (Voir le projet android-scripting de google)    

Pourquoi toujours ce fantasme du "on n'a pas besoin d'apprendre un nouveau langage" ? Pourquoi un langage pour tout faire ? Est-ce encore bien utile d'avoir ce débat au lieu de se concentrer sur les points forts et faibles de chaque "écosystème de développement" et de déterminer le plus adapté selon les besoins du projet ?

Pour être honnête, j'ai clairement un discours orienté de base sur php... J'ai commencé par développer avec ce langage mes premiers sites web mais... c'était avant de devenir développeur ! Aujourd'hui outre sa lenteur, je constate tous les jours des problèmes d'interopérabilité avec des éléments issus d’écosystèmes php... la faute première en revient bien sûr aux développeurs que j'ai en face plus qu'au langage, mais force est de constater des bêtises énormes (xml non conformes, wsdl non consommables par jax-ws et buggués sous axis2... ) qui de mon point de vue sont quasi impossible à avoir en production en utilisant java.

Et je pense que c'est un langage qui va finir par mourir, ne devant sa survie qu'aux possibilités d'hébergement pas cher qui le propose. (Et peut être aussi, hélas, à son accessibilité, permettant à des noobs de croire qu'ils savent développer... )

Des lors, pourquoi faire un portage d'un langage presque mort sur une techno en plein boom ? 

En tout cas, c'est le genre de petit gadget dont je suis plus que fan.. à bon entendeur.. :p

Tester correctement l'envoi d'email ne peut se faire que si l'on peut vérifier le message envoyé, son contenu, son destinataire... mais comment le gérer avec des tests unitaires, sans passer par une boite email "physique" ?

Après quelques recherches, je suis tombé sur trois libs, disponibles sur des repos maven :

1. wiser

C'est un mini serveur smtp dédié aux TU, qui stocke les emails dans une ArrayList interne.

Dépendance maven

<dependency>

 <groupId>org.subethamail</groupId>

 <artifactId>subethasmtp-wiser</artifactId>

 <version>1.2</version>

 <scope>test</scope>

</dependency>

Exemple d'utilisation dans une classe de test :

// le "serveur smtp"

private Wiser wiser;

// pour info/rappel, l'annotation 'org.junit.Before' permet d'éxécuter la méthode qui la porte avant chaque test. Ici, on initialise donc le serveur smtp

@Before

public void setUp() throws Exception {

    wiser = new Wiser();

    wiser.setHostname(smtpHost); // a priori, ne fonctionne qu'avec "localhost"

    wiser.setPort(smtpPort); // si non précisé, 25 par défaut

    wiser.start();

}

// de même, l'annotation 'org.junit.After' permet d'éxécuter une méthode après chaque tst. ici, on ferme le serveur stmp

@After

public void shutDown() {

    wiser.stop();

}

// exemple d'utilisation dans un test

@Test

public void simple_email_sending() {

    // appel d'un service d'envoi d'email

    mailService.sendMail(...);

    // un seul email doit avoir été envoyé

    assertEquals(1, wiser.getMessages().size());

    // on récupère le message

    WiserMessage message = wiser.getMessages().get(0);

    // on vérifie que le destinataire est le bon...

    assertEquals("[email protected]", message.getEnvelopeReceiver());

    // on vérifie le sujet de l'email...

    assertEquals("test", message.getMimeMessage().getSubject());

}

-> Voir la doc pour le reste ! :p

2. greenmail

S'utilise a priori comme wiser. Pas testé, un ancien collègue me l'a conseillé. La doc semble complète, il y a semble-t-il un souci avec spring mais un fix a déjà été proposé.

3. mock-javamail (voir http://www.touilleur-express.fr/2008/12/09/mock-javamail/)

En théorie, c'est encore plus simple que wiser ou greenmail : on ne configure pas de serveur smtp embarqué spécifique, la simple présence de la lib dans le path est censée surcharger les implémentations de javamail par les mocks (bouchons) de mock-javamail... dans la pratique, cela n'a pas fonctionné sur mon projet (conflit de dépendances maven ou java 6 ?) mais j'en parle tout de même car sur internet, les gens en sont assez satisfaits.

Par rapport à wiser, l'intêret est qu'avec cette lib on peut directement accéder à une boite email spécifique... a contrario, on ne peut donc pas réinitialiser le serveur entre les tests !