Web Driver

Aujourd'hui j'ai voulu tester quelques outils de test pour des applications web.

Pour cela j'ai crée une page simple avec un poil de javascript qu'on peut voir ici.

J'ai commencé par WebDriver, c'est un outil qui permet de manipuler un navigateur via du code en Java. Il se charge de manipuler le navigateur directement pour effectuer les actions demandées. (Contrairement à Selenium qui inclue sont propre javascript pour piloter le navigateur au travers de la page)

J'ai été étonné par la simplicité de mise en place de WebDriver, il m'a suffit de télécharger la distribution pour firefox, elle contient les deux ou trois jars nécessaires, d'ajouter ces jars à mon projet eclipse (et oui ce qui est bien en java c'est eclipse) et mon poste était prêt.

Voici un exemple simple qui ouvre la page en question, clique sur "++" et vérifie le changement de valeur :

WebDriver driver = new FirefoxDriver();
driver.get("http://jplessis.free.fr/polopblog/a_tester.html");
WebElement element = driver.findElement(By.name("test_button_inc"));
element.click();
WebElement field = driver.findElement(By.name("test_text"));
assertEquals("1", field.getValue());

Quelques petits problèmes néanmoins :

• Impossible de traverser un proxy nécessitant une authentification
• WebDriver ne sait pas encore gèrer les alertes et confirmations javascript

Pour voir le test complet que j'ai codé c'est ici (l'URL n'est pas bonne mais bon, vous devriez arriver à la rectifier).

Bienvenue dans un monde de psychopathes

Dans la série, je suis un psychopathe mais je ne me soigne pas, j'ai mis en place sur la plateforme d'intégration continue du projet sur lequel je travaille une série de tests que mes collègues on qualifiés de "tests de psychopathe"... ils sont charmants :)
On peut les séparer en 2 grandes catégories :

• les tests de psychopathe pouvant encore être soigné
• les tests de psychopathe fini

Dans la première catégorie, on y trouvera des tests que l'on pourrait qualifier de tests de "cohérence du code".
On y vérifie entre autres pour le langage C que les fichiers header d'API sont auto-suffisants, c'est à dire qu'ils ne nécessitent pas d'avoir à inclure 72 autres .h avant eux pour pouvoir les utiliser.
On vérifie également qu'il n'y a pas d'inclusion cycliques dans ces mêmes .h et qu'on ne vas pas chercher des .h ailleurs que là où ils sont censés être (pas d'inclusion bizarre en ../../../polop/toto.h, ne riez-pas ça s'est déjà vu... voire pire en d:/dev/mon_projet/ma_version/polop/toto.h --sic--).
D'autres concernent les déclarations de types d'énumération afin d'éviter de déclarer 2 fois les mêmes, ou 2 définitions différentes pour la même valeur.

Dans la deuxième catégorie on y trouve des tests beaucoup plus amusants :), qui vont cette fois vérifier la cohérence dans l'écriture du code, autrement dit, les conventions de codages.
Dans beaucoup de projets, au tout début on essaye tous d'ériger des règles de codages, auxquelles on se tiens les premiers jours, puis la lassitude vient (en général au bout de quelques jours pour les plus acharnés) et on oublie ces belles règles. Pour éviter cela, rien de mieux que de mettre en place une convention de codage automatique :).
La première règle de codage que j'ai mise en place portait sur l'indentation des fichiers. Développant en grande partie en python, où l'indentation est au coeur du langage puisqu'elle défini les blocs fonctionnels (déclaration de fonction, classe, bloc de condition...), il paraissait logique de fixer une règle et de ne pas en déroger, on indente avec des tabulations et uniquement avec des tabulations (tabulations à 4 ou à 8 espaces, chacun est libre du moment que ce ne sont que des tabulations qui terminent dans le fichier). A l'opposé pour le langage C, on indente uniquement avec des espaces (3 par niveau de tabulation) où même si l'indentation ne fait pas partie du langage, elle aide énoooooormément à la lisibilité du code, je vous rappelle au passage que le boulot d'un développeur est en majeure partie fait de relecture de code pour le corriger ou le modifier légèrement, faire en sorte que le code soit lisible peut faire une grande différence !
Là où le délire de psycopathe va un peu plus loin, c'est quand je teste qu'il ne reste pas d'espace en fin de ligne. Vous allez me dire, "mais pourquoi tant de haine ? Ca ne change rien d'avoir des espaces qui traînent".... et bien si justement, la preuve ici. Ahahah, non seulement c'est justifié, mais en plus ca prouve que je ne suis pas le seul psycopathe au monde :-D

M'enfin, le résultat de tous ces tests de codage, c'est que le code produit dans notre équipe est de manière générale plus homogène et plus "standard" selon nos normes, cela simplifie sans aucun doute l'intégration de nouveaux développeurs et si cela n'accélère pas le développement de nouvelle fonctionnalités, la maintenabilité du code est accrue.

Le Pomodoro

Bonjour, bonjour...
Aujourd'hui je voudrais vous faire part d'une technique intéressante que j'ai découverte grâce à cet article sur les pratiques agiles d'Emmanuel CHENU.

Il s'agit du pomodoro ! Pomodoro veut dire tomate en Italien car la technique est basée sur l'utilisation d'un minuteur type minuteur de cuisine (souvent en forme de tomate :) )

Tout d'abord le contexte : Francesco Cirillo, étudiant à l'époque de la mise au point de cette technique, s'est rendu compte que les gens avait du mal à travailler/étudier correctement. Plusieurs raisons à cela : le stress, la peur du temps qui passe (et des deadlines qui approchent), le manque de concentration, etc. Il a alors réflechi à comment améliorer cela, comment gagner en productivité.

Sa solution : le pomodoro. L'idée est la suivante :

1. On prépare une liste de tâches à faire pour la journée
2. On prend la première tâche
   
3. On remonte le pomodoro à 25 minutes et c'est parti, on travail sur cette tâche sans s'arrêter jusqu'a ce que le pomodoro sonne !
4. On place un X à coté de la tâche en cours
   
5. Ensuite pause de 3-5 minutes pour se reposer et laisser notre cerveau intégrer toutes les nouveautés
6. Puis on reprend à l'étape 3 jusqu'a ce que la tâche soit entièrement terminée
7. Tous les quatres pomodoros, une pause plus longue (15-30 minutes)
   
8. En fin de journée on consacre un pomodoro à noter les résultats de la journée à des fins de mesures et d'amélioration

Sur cette idée de base viennent s'ajouter des objectifs :

1. Objectif qualitatif des pomodoros c'est à dire supprimer les intéruptions internes (j'vais aller manger un morceau, j'ai soif, j'ai envie de faire pipi, tiens j'vais aller voir mes mails) et externes (une personnes qui vient demander quelque chose, un coup de téléphone, un mail qui arrive). Sachant que tout pomodoro qui est intérrompu n'est pas compté comme effectué.
   
2. Objectif d'estimation c'est à dire être capable de déterminer combien de pomodoros sont nécessaire à une tâche mais aussi combien de pomodoros sont disponibles dans une journée.
3. Amélioration de l'éfficacité en réfléchissant à la structure même d'un pomodoro (par exemple les 3 premières minutes servent à réviser ce que l'on à vu depuis le début de la tâche, les 3 dernières à confirmer ce qui a été fait au cour de ce pomodoro)
4. Préparation d'un emploi du temps afin de déterminer en fonction des horaires de travail la manière dont les pomodoros seront agencés.

Attention, tous ces objectifs ne sont pas à remplir dès le début ! Allons y doucement, pomodoro après pomodoro.

Le résultat attendu de cette technique est d'améliorer notre perception du temps et d'inverser la tendeance, ce n'est plus le temps qui passe et qui nous maitrise, c'est nous qui maitrisons le temps qui passe et ce que nous en faisons.
De même pour l'objectif qualitatif on modifie le rapport que nous avons vis-à-vis des interuptions, ce ne sont plus elles qui viennent nous déranger, c'est nous qui choisissons de les ignorer temporairement pour y revenir plus tard lorsqu'elles auront une priorité suffisante.

En lisant le document consacré au pomodoro (dont le lien se trouve en fin de cet article), j'ai eu l'impression de reconnaître le processus que nous appliquons au niveau des méthodes agiles. La liste des choses à faire ce jour correspond au contenu de l'itération courante, la préparation de début de journée, c'est le planning game, il y a aussi une notion de backlog, en fin de journée on à une rétrospectives avec statistiques et réflexion sur les axes d'amélioration. Et les pauses ? Le rythme durable :)

Je n'ai malheureusement pas eu le temps de tester par moi-même cette technique, j'ai néanmoins constaté que depuis que j'ai commencé à écrire cet article j'ai été intérompu au moins deux fois par "l'extérieur"... Ce qui prouve bien qu'il y a un réel travail à faire sur la manière dont on travail.

Pour plus de détails je vous laisse aller voir le pdf sur la technique du pomodoro.

shunit2

Hello,
j'inaugure donc ce blog avec un article sur shunit2.

Comme son nom l'indique shunit2 est un utilitaire dans la lignée des XUnit, dont le but est d'écrire des tests unitaires pour un script shell.

Tout d'abord comment l'installer :

• Rendez-vous sur http://code.google.com/p/shunit2/downloads/list
• Téléchargez et décompressez le tgz
• Puis un petit make build devrait faire l'affaire
  
• Copier shunit2 depuis le répertoire build vers le répertoire de votre choix (/usr/bin par exemple)

Vous êtes maintenant prêt à écrire votre premier test unitaire shell. Pour cet article nous allons créer un script qui va permettre de calculer si une année est bisextile (exemple bateau s'il en est).

Allons-y, étant de vrais barbus, on y va mais TDD !

Dans le fichier is_leap_test.sh :

testNeedsParameter()
{
STANDARD_OUT=`sh is_leap.sh`
assertEquals 2 $?
assertEquals "Usage : is_leap.sh YEAR" "$STANDARD_OUT"
}

. shunit2

Si vous exécuté ce script vous obtenez ceci :

#
# Performing tests
#
testNeedsParameter
sh: Can't open is_leap.sh
ASSERT:expected: <Usage: is_leap.sh YEAR> but was:<>

#
# Test report
#
tests passed: 1 50%
tests failed: 1 50%
tests skipped: 0 0%
tests total: 2 100%

La moitié des assertions ont échouées, le message d'erreur nous indique que la sortie standard ne contient pas le texte attendu. Par contre le script à bien retourné le code de sortie attendu... Ce qui veux dire que sh renvoi un code de sortie 2 lorsqu'il ne trouve pas le fichier à exécuter...

On note au passage que même si une assertion échoue, les tests restants ainsi que les assertions suivantes du même test sont quand même exécutés.

Passons donc au code de notre script :

#!/usr/bin

if [ $# -ne 1 ]; then
echo "Usage : $0 YEAR"
exit 2
fi

et maintenant notre test renvoi

#
# Performing tests
#
testNeedsParameter

#
# Test report
#
tests passed: 2 100%
tests failed: 0 0%
tests skipped: 0 0%
tests total: 2 100%

Voilà ! Je m'arrête là pour la démonstration de shunit2, vous trouverez le code complet du test et du script là : testShunit2.tgz

polop

polop was here :)