Catégorie : Méthodologies et bonnes pratiques

Par Fabian Piau, le 15 février 2012

Offrez un petit coup de jeune à votre application

Même exempte de bogue, une application dont l’ergonomie n’a pas été bien pensée sera surement un frein pour l’utilisateur. Il est donc important de prendre un peu de temps pour améliorer le design et l’ergonomie d’une application. Même si un client ne le spécifie pas directement dans le cahier des charges, il sera toujours plus plaisant pour lui d’utiliser une application « user-friendly ». L’identité visuelle n’est pas en reste et ne doit pas être négligée. Elle est même primordiale dans certains secteurs où la concurrence est forte comme la vente en ligne ou la publicité.

Cet article va vous montrer qu’il est possible d’améliorer le design général d’une application à moindre coût. En quelques minutes, vous allez voir comment apporter une petite touche en plus à vos formulaires.

Lire la suite
Par Samuel Romero, le 20 décembre 2011

AGILE TOUR PARIS 2011 - A la recherche du temps perdu...

Comme je vous l'annonçais dans mon précédent billet, j'étais début décembre dans les locaux de Microsoft pour assister à l'Agile Tour de Paris. Je remercie tout d'abord les organisateurs de cet événement car nous avons été reçus aux petits soins, et les conférences se sont déroulées dans un timing parfait!

Je vous propose ici de revenir sur une des conférences que j'ai le plus appréciée, "A la recherche du temps perdu", animée par Jean-Charles Meyrignac (ScrumMaster & Developer), dont le slogan pourrait se résumer en "Travailler moins, plus intelligemment, pour en faire plus!"; ou comment mieux organiser son temps personnel pour être plus productif.

Lire la suite
Par joan David, le 01 décembre 2011

Afficher les informations de build maven sur la page d'accueil

Lorsqu'une application web évolue, les livraisons peuvent être nombreuses et régulières que ce soit en test, en pré-production ou en production.

Pour pouvoir rapidement savoir sur quelle version de l'application on navigue, les informations de version et de date de construction peuvent servir.

Lire la suite
Par Alexandre Lacroux, le 15 novembre 2011

Tests fonctionnels en intégration continue

Introduction

Tout au long de ce blog, je vais vous présenter une manière de jouer des tests fonctionnels en intégration continue. L’avantage de la méthode décrite ici est qu’elle est totalement décorélée du langage de programmation de l’application à tester. En effet, les tests fonctionnels ne concerne que la couche web de l’application : ils sont directement enregistrés et joués sur le navigateur.

Jouer des tests fonctionnels en intégration continue permet d’avoir une vision globale, continue et en temps réel de l’état de fonctionnement de l’application web.

Outils

Selenium

L’outil que nous allons utilisé pour enregistrer les tests fonctionnels est Selenium (http://seleniumhq.org/). Il permet d’enregistrer les actions de l’utilisateur sur l’application web à tester (cliques, saisies de textes, navigations etc) et de les rejouer à la demande, sur la même adresse où sur une adresse différente (pour tester plusieurs environnements avec les mêmes tests). Par défaut, les tests sont enregistrés au format xml, ce qui permet de les ré-ouvrir et de les modifier directement dans Selenium IDE. Le principal avantage de Selenium, qui est par la même occasion la raison pour laquelle nous allons l’utiliser, est qu’il permet ensuite d’exporter les cas de tests sous différents formats : Ruby, Groovy, Perl, PHP, Python et C#, sans oublier JUnit 3 et JUnit 4.

Maven

Le but de ce blog n’est pas d’expliquer le fonctionnement de ce framework que l’on ne présente plus. Précisons tout de même qu’il permet de jouer tous les tests d’un projet grâce à une simple ligne de commande.

Hudson & SVN

Hudson est un serveur d’intégration continue, qui permet de construire les projets qui lui sont confiés. Concrètement, dans la cas d’un projet sous maven puisque c’est de ça qu’il s’agit, il peut lancer une commande maven à l’aide de “job” que l’utilisateur doit paramétrer. Il peut, entre autres, régler la fréquence à laquelle les jobs sont exécutés.

Il est possible de relié ce serveur d’intégration continue à un serveur de gestion de version, dans notre cas SVN. A chaque modification des sources sur le serveur SVN, Hudson récupère les sources impactées pour être en permanence à jour.

Mise en place

Etape 1 : Enregistrement des tests avec Selenium

Nous allons utiliser 2 composants de la suite Selenium :

  • Selenium IDE, qui est un plugin Firefox qui permet d’enregistrer les tests.
  • Selenium Remote Control, qui contient le serveur Selenium chargé de jouer les tests à distance.

Ces deux composants sont disponibles gratuitement à l’adresse suivante : http://seleniumhq.org/download/

Grâce au premier, on enregistre donc nos tests fonctionnels directement sur l’application web. Ce composant permet d’enregistrer les actions de l’utilisateur, tels que les cliques, les saisis de textes ou les navigations. Une fois le test enregistré au format xml par le plugin, choisissons dans le menu de l’exporter au format JUnit 4.

Le second composant (Selenium RC) servira à jouer ce test lorsqu’il sera lancé en tant que test unitaire. Pour lancer le serveur Selenium situé dans l’archive téléchargée, la commande est la suivante :

java -jar selenium-server

Le serveur Selenium est lancé et prêt à recevoir des tests à jouer sous firefox.

Etape 2 : Création du projet maven

Pour créer un projet maven vide qui contiendra uniquement les tests, nous allons utiliser le plugin archetype. Il suffit de se positionner dans le workspace est d’exécuter la ligne suivante :

mvn archetype:generate -DgroupId=com.javaworld.projet -DartifactId=projet-selenium -Dversion=1.0

Une fois le projet de tests créé, importons les tests et ajoutons la dépendance suivante à notre pom.xml :

 <dependency>
<groupId>org.seleniumhq.selenium.client-drivers</groupId>
<artifactId>selenium-java-client-driver</artifactId>
<version>1.0.1</version>
</dependency>

A noter que dans le test JUnit exporté par Selenium IDE, dans la méthode setUp() exécuté avant la méthode de test, le constructeur utilisé pour instancier l’objet “selenium” prend en paramètres : DefaultSelenium(String serverHost, int serverPort, String browserStartCommand, String browserURL)

  • serverHost : l’adresse du serveur Selenium RC (localhost s’il tourne en local, l’adresse d’une VM dédiée dans l’idéal)
  • serverPort : le port d’écoute du serveur Selenium RC (4444 par défaut)
  • browserStartCommand : la commande de lancement du navigateur à utiliser pour jouer les test (*firefox par exemple)
  • browserUrl : l’adresse de l’application à tester

Maintenant, il faut déposer les sources sur le serveur SVN pour que Hudson puisse les récupérer.

Etape 3 : Création du job hudson

Nous allons maintenant créer un job Hudson qui sera en charge de jouer nos tests périodiquement à l’aide d’une commande maven.

Lors de la création d’un job, de nombreux réglages plus ou moins utiles sont proposés. Dans notre cas, il suffit de renseigner :

  • Gestion de code source : sélectionner “Subversion” et indiquer l’adresse du trunk du projet sur le serveur SVN dans la partie “URL du repository”;
  • Ce qui déclenche le build : si on ne touche rien, le build doit être déclenché manuellement par un utilisateur. Sinon, nous pouvons charger Hudson de le faire pour nous à des fréquences paramétrables (“Construire périodiquement”);
  • Buid : sélectionner “Invoquer des cibles maven de haut niveau”. La cible maven est la suivante : “clean test” (pour “nettoyer” le projet puis jouer l’intégralité des tests);
  • Actions à la suite du build : dans notre cas, il peut être intéressant de renseigner “Publier le rapport des résultats des tests JUnit”.

On peut maintenant sauvegarder le job, puis le lancer.

Résultat

Lorsque le job est lancé par le serveur Hudson, les tests sont lancés et donc exécutés par le serveur selenium sur l’application web disponible sur la plate-forme cible. Bien sûr, pour que le suivi de l’exécution des tests dans le temps ait un intérêt, il faut déployer régulièrement l’application en cours de développement sur la plate-forme cible. Il existe pour cela des plugins maven de déploiement automatique.

Conclusion

Grâce à cette solution, nous sommes capables de jouer des tests fonctionnels en intégration continue. L’ensemble des outils utilisés sont gratuits et open source, et la mise en place de la solution est rapide.

Par Johann Glantenay, le 14 novembre 2011

Configuration d'un serveur SMTP de test

Tester l'envoi de mail peut parfois se révéler pénible et potentiellement dangereux. Une solution consiste à modifier systématiquement l'adresse des destinataires, malheureusement un oubli est vite arrivé. Une autre solution est l'utilisation en test et en pré-production d'une librairie qui n'envoie pas les mails mais il devient alors impossible de vérifier que les mails envoyés son corrects.

Pour sécuriser ces envois, il est possible de configurer un serveur SMTP pour qu'il redirige tous les e-mails vers une boîte locale. Cela permettra de configurer les applications de test ou de pré-production de manière très simple : En changeant simplement l'adresse du serveur SMTP utilisé aucun mail de test ne partira chez un client. Ce système permet aussi d'accéder aux e-mails comme si on en était le destinataire.

Pour cela j'aurai besoin d'installer un serveur postfix et un serveur courier-imap. L'installation se fera sur une machine ubuntu mais la configuration de postfix est évidemment valable sur n'importe quelle distribution linux.

Installation du serveur postfix

pour installer le serveur postfix j'utilise la commande suivante

sudo aptitude install postfix

ou

sudo apt-get install postfix

selon vos petites habitudes...

Le système propose différentes options de configuration, je choisis "Pas de configuration".

Je crée le fichier [/etc/postfix/main.cf] avec seulement trois petites lignes.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


default_transport = local
luser_relay= dev
home_mailbox = Maildir/

La première ligne indique que le serveur livre par défaut les mails en local. La deuxième ligne précise que les mails seront déposés sur le compte de l'utilisateur "dev". Il s'agit de l'utilisateur linux. La troisième ligne définit le répertoire dans lequel Postfix stockera les mails.

Test du serveur postfix

Pour tester notre nouveau serveur, le plus simple est d'utiliser la commande "mail". On évite ainsi de devoir configurer exprès un logiciel de mail. Par défaut la commande mail utilise "localhost" comme serveur smtp.

Si la commande mail n'est pas installée :

sudo aptitude install mailutils

puis on envoie un mail avec la commande suivante :

echo "Message de test" | mail test@test.com -s "Test `date`"

On vérifie dans le répertoire [/home/dev/Maildir/new/] la présence d'un fichier. Afficher ce fichier devrait donner à peu près cela :

more Maildir/new/1318834019.V805I1ef58M800270.net26p

Return-Path: <utilisateur[[@net26p.localdomain]]>
X-Original-To: test@test.com
Delivered-To: test@test.com
Received: by net26p.localdomain (Postfix, from userid 1000)
	id C25C7EE2D; Mon, 17 Oct 2011 08:46:59 +0200 (CEST)
**Subject: Test lundi 17 octobre 2011, 08:46:59 (UTC+0200)**
To: <test@test.com>
X-Mailer: mail (GNU Mailutils 2.1)
Message-Id: <20111017064659.C25C7EE2D@net26p.localdomain>
Date: Mon, 17 Oct 2011 08:46:59 +0200 (CEST)
From: Utilisateur[[@net26p.localdomain]] (Nom Utilisateur)


**Message de test**

Installation du serveur courier-imap

Cette partie est facultative mais vous permettra d'autoriser l'accès aux mails de tests à toutes les personnes que vous souhaitez.

Là encore rien de bien compliqué :

sudo aptitude install courier-imap

La configuration par défaut permet de l'utiliser

Test du serveur courier-imap

Dans mon logiciel de mail préféré, je configure un serveur IMAP avec l'adresse IP de mon nouveau serveur, les identifiants de l'utilisateur "dev" et je peux lire les messages. L'adresse de destination est bien la véritable adresse donc cela me permet de vérifier à qui le mail aurait du être envoyé.

Par Ludovic Chaboud-Paupi, le 20 septembre 2011

SONAR : La chasse aux 7 péchés du développeur

JUG Summer Camp

Durant le JUG Summer Camp 2011 qui a eu lieu à La Rochelle, Olivier Gaudin de la société SonarSource a présenté l’inspection continue du code source avec Sonar.

Olivier a détaillé les 7 péchés communément commis par les développeurs et comment les aider à améliorer la qualité technique des applications.

JUG Summer Camp 2011 - Sonar - Olivier Gaudin

Lire la suite
Par Karim LITIM, le 09 septembre 2011

L'interface fluide : vers un code orienté métier

Introduction

La maintenabilité d'une application dépend fortement de la lisibilité du code source sous-jacent. Cette lisibilité peut être améliorée par : 

  • l'introduction (mesurée) de commentaires dans le code
  • la présence sysématique de Javadoc
  • la vérification automatique à l'aide d'outils comme CheckStyle et PMD (règles de nommage, mesure de complexité...etc)
  • la revue de code effectuée par un développeur tiers
L'objectif de ce billet est de présenter une technique supplémentaire permettant d'améliorer la lisibilité du code : l'interface fluide

Exemple

public class Person {
    
    private String firstName;
    private String lastName;
    private Person father;
    private Person mother;
    public void setFirstName(String firstName){
        this.firstName = firstName
    }
    public void setLastName(String lastName){
        this.lastName = lastName
    }
    public void setFather(Person father){this.father = father}
    public void setMother(Person mother){this.mother = mother}
  
    //Getters volontairement omis pour plus de clarté
    ...
}

Ceci est une classe Person pouvant servir d'entité dans une application d'arbre généalogique. Créons un objet de ce type : 

//La personne
Person person = new Person();
person.setFirstName("Youri");
person.setLastName("Gagarine");
//Le papa
Person father= new Person();
father.setFirstName("Alexeï");
father.setLastName(" Ivanovitch");
//La maman
Person mother = new Person();
mother.setFirstName("Anna");
mother.setLastName("Timofeïevna");
//La famille
person.setFather(father);
person.setMother(mother);



Premier constat : ce code est verbeux. On aimerait qu'il ressemble à : 
//La personne
Person person = new Person().setFirstName("Youri").setLastName("Gagarine");
//Le papa
Person father= new Person().setFirstName("Alexeï").setLastName("Ivanovitch");
//La maman
Person mother = new Person().setFirstName("Anna").setLastName("Timofeïevna");
//La famille
person.setFather(father).setMother(mother);

Notre code est désormais à la fois moins verbeux et beaucoup plus lisible. Même une personne non-technique pourrait lire : 
  • Créer  une première personne dont le prénom et le nom....
  • Créer  une deuxième personne dont le prénom et le nom....
  • Créer  une troisième personne dont le prénom et le nom....
  • Lier la première personne au deux autres à l'aide des liens de paternité et de maternité.
Pour pouvoir bénéficier de cette "expressivité", il suffit de modifier les setters de la classe Person afin que chacun de ces setters renvoie l'objet this

public class Person {
    .....
    public Person setFirstName(String firstName){
        this.firstName = firstName; 
        return this;
    }
    public Person setLastName(String lastName){
        this.lastName = lastName;
        return this;
    }
    public Person setFather(Person father){
        this.father = father ;
        return this;
    }
    public Person setMother(Person mother){
        this.mother = mother ; 
        return this;
    }
    ...
}

Ici, on renvoie l'objet this mais rien n'empêche de renvoyer un objet d'un autre type. L'objectif de cette approche est de concevoir une API centrée sur le métier de l'application que l'on désire développer (Domain Specific Language). A titre d'exemple, L'API Criteria dans JPA 2.0 utilise cette technique pour construire les requêtes.

Conclusion

L'interface fluide aide à concevoir un code concis et orienté métier.

Références

Par Karim LITIM, le 28 août 2011

Gestion des versions dans Maven: SNAPSHOT ou pas SNAPSHOT?

Introduction

MAVEN est un outil qui permet de gérer le cycle de vie d'un projet d'une manière portable. Parmi les fonctionnalités les plus importantes, on peut citer :

  • la structure du projet qui est normalisée et indépendante du langage et de la plateforme utilisés (Java, PHP, FLEX...);
  • l'incitation à utiliser un dépôt central abritant les librairies utilisées par nos projets et assurant le stockage des ces derniers pour une utilisation tierce (livraison à un client ou bien utilisation par un autre projet).
Un aspect important dans l'utilisation de MAVEN est la gestion des numéros de version d'un projet et de ses dépendances. En effet, avec MAVEN, j'ai découvert la notion de SNAPSHOT et l'objectif de ce billet est de partager mon retour d'expérience concernant :
  • La mise en place d'une pratique commune de versionning.
  • La mise en place d'un déploiement continu.
  • L'automatisation de la distribution d'un projet.
Lire la suite
Par Pawel Firsowicz, le 28 juin 2011

Astuces : chercher et remplacer une chaîne de caractères dans plusieurs fichiers

S'il vous est déjà arrivé de chercher et remplacer une chaîne de caractères dans plusieurs fichiers, vous vous rendez bien compte qu'une telle tâche peut s'avérer laborieuse !

Voici la ligne de commande qui va vous sauver : perl -pi -w -e 's/MOT_A_CHERCHER/MOT_DE_SUBSTITUTION/g;' *.txt

Lire la suite
Par Kodjo Agbemebia, le 08 février 2011

Utilisez TestLink pour gérer vos cas de tests.

TestLink est un outil de gestion de cas de tests (Test Case Manager). C'est une plateforme web (Open Source) écrite en PHP, qui vous permet d'organiser vos cas de tests sous forme de plans de tests. Elle permet de centraliser toute la gestion des tests fonctionnels autour d'une unique interface web accessible à tout moment, et à toute l'équipe de projet (clients, prestataires, etc..).

Lire la suite