Les Tests en Trois Temps (3T) en pratique

Il est important de noter que « 3T » n'est en aucun cas une méthode « officielle », contrairement aux TDD. « 3T » est une proposition de simplification des TDD qui devrait suffire à la plupart des équipes. En effet, mon expérience personnelle, liée à l'utilisation de Xp, de Scrum et bien entendu des TDD, me conduit à croire que les développeurs n'utilisent pas tout (certains aspects des TDD sont difficiles à faire et mangent beaucoup de temps), mais se concentrent sur certains points importants dont « 3T » est un résumé cadré. On peut voir « 3T » comme la formulation d'une pratique de simplification dont l'objectif est de gagner du temps (et de l'argent). Dans cet article, « 3T » est associée à Scrum, ce qui permet d'en suivre la mise en place à travers un projet fictif. C'est une simple illustration.

« 3T » n'invente rien ; c'est seulement un résumé cadré d'autres méthodes. Les termes employés dans cet article ne sont pas nouveaux. Voici néanmoins quelques définitions rapides.

Scrum et Xp : ce sont deux méthodes agiles, souvent associées.

Sprint : dans Scrum, un Sprint correspond à une période (généralement 2-4 semaines) durant laquelle on doit développer un ensemble donné de fonctionnalités.

Dashborad : dans Scrum, il s'agit d'un tableau comportant trois colonnes : à faire, en cours et fait. Les fonctionnalités à développer durant le sprint sont indiquées sur des Post-It. Ces derniers changent de colonne en fonction de l'avancement. À la fin du sprint, tous les Post-It doivent être passés de la colonne des choses à faire à la colonne des choses faites.

Le sprint backlog : Il s'agit simplement du nom Scrum de la colonne des choses à faire dans le dashboard. Cette colonne est généralement positionnée à gauche.

La société « Chien-Copain » commercialise une gamme moderne de produits canins fabriqués dans ses usines dans le respect de l'environnement. L'enseigne s'est constitué une clientèle fidèle et régulière.

À l'occasion de l'ouverture de son vingtième magasin, la société « Chien-Copain » souhaite se doter d'un service de vente en ligne dont le nom sera « la Boutique du Chien-Copain ». L'entreprise dispose déjà d'outils de comptabilité et de gestion de ses stocks ainsi qu'un site vitrine sur Internet.

La Web Agency « Green Soft », qui avait déjà réalisé le site « www.chien-copain.fr » et dont les prestations avaient été appréciées, a naturellement été choisie pour développer la nouvelle application.

Dans le cadre de cet article, pour simplifier l'explication, on ne s'intéressera qu'à une sous-partie de la boutique en ligne : la génération d'un mot de passe et son cryptage.

Pour illustrer l'utilisation de « 3T » et les phases préparatoires, cet article met en scène une poignée d'acteurs. Certains sont des personnages principaux tandis que d'autres ont un rôle symbolique.

Je me suis attaché à bien séparer les rôles (responsabilités) pour mettre en évidence les possibilités de la méthode, notamment en termes de parallélisation des tâches. On gardera toutefois en tête que, dans la vraie vie, les membres de l'équipe rempliront plusieurs fonctions.

II-B-1. La cliente (Claire)▲

Claire est salariée de « Chien-Copain ». C'est d'ailleurs la seule de cette histoire ; tous les autres personnages travaillent pour « Green Soft ». Claire est en charge de la boutique en ligne. Elle écrit et gère le cahier des charges. Elle a pouvoir de décision.

II-B-2. L'architecte (Laurent)▲

Laurent possède une solide expérience du développement. Il fréquente assidument les blogs des grandes SSII et les conférences. Pour lui, la réussite d'un projet passe nécessairement par les tests et il prend son rôle d'évangélisation au sérieux.

II-B-3. Le chef (Michel)▲

Michel a lui aussi de la bouteille. Il déjeune souvent avec Laurent, mais trouve que les TDD (Développement Dirigé par les Tests) sont trop complexes, d'autant qu'il a du mal à les faire accepter par sa hiérarchie pour des raisons budgétaires et à les imposer au sein de ses équipes. Il a découvert « 3T »sur developpez.com et compte bien l'appliquer sur le projet de la « Boutique du Chien-Copain ». C'est aussi un adepte des méthodes agiles et plus particulièrement de Scrum depuis qu'il a lu le livre « Scrum et Xp depuis les tranchées » sur Internet.

II-B-4. Les développeurs (Julie, Sébastien et John)▲

II-B-5. La secrétaire (Vanessa)▲

Vanessa ne joue pas un rôle important dans l'histoire. Elle ne fait même pas partie du projet. Elle incarne l'élément perturbateur : ses passages dans le bureau font chuter dramatiquement le niveau général de concentration et la productivité de l'équipe. Il faut préciser que Vanessa est charmante.

II-B-6. Le testeur (Bernard)▲

Arrivant en bout de chaine, lors de la phase de qualification, Bernard s'assure que le logiciel livré est conforme au cahier des charges dont Claire lui a envoyé une copie. Si tout est bon, il appose son cachet sur le bon de livraison, mais sinon il répond par un refus franc au chef de projet.

Après une prompte analyse, l'équipe se réunit pour définir un jeu de Post-It, relatif aux fonctionnalités décrites dans le cahier des charges. En effet, Michel (le chef de projet) a choisi d'appliquer « 3T » lors du développement du projet (cf. les conversations en annexes) et souhaite travailler avec les outils les plus simples (i.e. les Post-It), ce qui aura un avantage plus tard lors des « Sprints Scrum ».

III-A-1. Les Post-It généraux (jaunes)▲

III-A-2. Les Post-It détaillés (bleus)▲

III-A-3. Les Post-It techniques (orange)▲

III-A-4. Le cahier des charges modifié▲

Chaque membre de l'équipe choisit un (ou plusieurs) Post-It à traiter sur le « dashboard ». Dans le cadre de cet article, l'illustration va se limiter aux Post-It présentés ci-dessus. Disons que Julie prend le Post-It « RG023 » et que Sébastien prend le Post-It « RG024 ». Quant à John, il s'occupe d'un Post-It qui n'est pas présenté dans cet article.

Pour commencer, Julie crée l'interface « PasswordGenerator » correspondant au Post-It « RG023 » et y ajoute la méthode « generate() ». Elle documente son code en recopiant les numéros de Post-It. L'opération ne dure que quelques minutes.

package fr.chiencopain.boutique.service.credentials;

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023
 * 
 * @author Julie
 * 
 */
public interface PasswordGenerator {

    /**
     * Genere un mot de passe.
     * 
     * REGLE RG023
     * 
     * @return
     */
    String generate();
}

Pour bien faire, Julie crée aussi la classe « DefaultPasswordGenerator » qui servira d'implémentation pour le service qu'elle vient de définir.

package fr.chiencopain.boutique.service.credentials;

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author Julie
 * 
 */
public class DefaultPasswordGenerator implements PasswordGenerator {

    /**
     * REGLE RG023, RG023.1, RG023.2
     * 
     * {@inheritDoc}
     */
    public String generate() {
        // TODO Cette methode n'est pas encore developpee.
        throw new UnsupportedOperationException("Cette methode n'est pas encore developpee.");
    }
}

Finalement, Julie indique sur le Post-It que sa partie est réalisée. Pour simplifier le travail de la personne qui prendra le relais (cf. plus bas), Julie ajoute quelques remarques au verso des Post-It.

De son côté, Sébastien réalise un travail, équivalent à celui de Julie, pour le Post-It « RG024 ». Il commence par créer l'interface « Encryptor ».

package fr.chiencopain.boutique.util.encryption;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024
 * 
 * @author Sebastien
 * 
 */
public interface Encryptor {

    /**
     * Crypte le message passe en parametre. <br/>
     * 
     * REGLE RG024
     * 
     * @param message
     * @return
     */
    String encrypt(String message);
}

Ensuite il crée l'implémentation vide « MD5Encryptor » qui recevra le code pour le cryptage MD5.

package fr.chiencopain.boutique.util.encryption;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024, RG024.1
 * 
 * @author Sebastien
 * 
 */
public class MD5Encryptor implements Encryptor {

    /**
     * REGLE RG024, RG024.1
     * 
     * {@inheritDoc}
     */
    public String encrypt(String message) {
        // TODO Cette methode n'est pas encore developpee.
        throw new UnsupportedOperationException("Cette methode n'est pas encore developpee.");
    }
}

Puis, comme Julie, il met à jour ses Post-It en indiquant son avancement.

À partir du code source ainsi écrit, ne comportant pour l'instant que des interfaces, on peut générer un peu de documentation, et notamment des rapports.

Dans la configuration du projet Maven (cf. pom.xml en annexes), j'ai inclus plusieurs plugins spécialisés dans le reporting. Deux d'entre eux vont immédiatement servir à Michel (le chef de projet) bien que peu d'éléments aient été réalisés.

D'abord le plugin « Tag list » permet de répertorier toutes les références aux règles dans le code ainsi que les travaux (programmés) restant à faire à ce stade.

Ensuite, le plugin « Cobertura » mesure la couverture du code (c'est-à-dire la quantité de tests). À ce stade, les résultats indiquent en toute logique un score de zéro.

Note : Ces données peuvent être consultées tout au long du projet. Il n'est pas nécessaire d'attendre que les phases successives de « 3T » soient terminées, d'autant que plusieurs Post-It, dans des phases différentes, peuvent être traités simultanément, comme le laisse deviner le « dashboard » suivant.

Maintenant que plusieurs Post-It ont franchi le cap de « T1 » (c'est-à-dire le premier temps), les développeurs qui piochent dans le « sprint backlog » peuvent choisir entre des Post-It « vierges » et des Post-It à faire évoluer vers « T2 ». Bien évidemment, c'est ce second choix que va illustrer cet article.

Disons que Julie prend en charge l'écriture des tests pour les Post-It « RG024.x » et que John s'occupe de « RG023.x ». De son côté, Sébastien travaille sur d'autres Post-It, non présentés dans cet article, ou alors il est en RTT, ou encore il prend une pause. Bref il fait autre chose.

John prend donc en charge les Post-It « RG023.x » pour lesquels il doit écrire les tests unitaires. Globalement, il suffit de se concentrer sur les deux Post-It bleus « RG023.1 » et « RG023.2 ».

package fr.chiencopain.boutique.service.credentials;

import static junit.framework.Assert.assertEquals;
import static junit.framework.Assert.assertNotNull;
import static junit.framework.Assert.assertTrue;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

import org.junit.Before;
import org.junit.Test;

/**
 * Tests de DefaultPasswordGenerator.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author John
 * 
 */
public class DefaultPasswordGeneratorTest {
    /**
     * PasswordGenerator
     */
    PasswordGenerator passwordGenerator;

    /**
     * DefaultPasswordGenerator
     */
    @Before
    public void doBefore() {
        passwordGenerator = new DefaultPasswordGenerator();
    }

    /**
     * Le mot de passe genere sera compose de 8 digits. <br/>
     * 
     * REGLE RG023.1 <br/>
     * 
     * RESULT : length = 8 <br/>
     * 
     * Exemple a : football <br/>
     * Exemple b : voitures
     */
    @Test
    public void testGenerate_RG023_1() {
        // Param
        final int tailleAttendue = 8;

        // Appel
        final String password = passwordGenerator.generate();

        // Tests
        assertNotNull(password);
        assertEquals(tailleAttendue, password.length());
    }

    /**
     * Le mot de passe genere sera compose des 26 lettres de l'alphabet, en
     * majuscules et/ou en minuscules, et des chiffres de 0 à 9. <br/>
     * 
     * REGLE RG023.2 <br/>
     * 
     * Exemple a : abcd1234 <br/>
     * Exemple b : Hello012
     */
    @Test
    public void testGenerate_RG023_2() {

        final String lettresAutoriseesRegex = "[a-zA-Z0-9]+";

        // Appel
        final String password = passwordGenerator.generate();

        // Tests
        assertNotNull(password);
        assertTrue(verifyRegex(lettresAutoriseesRegex, password));

    }

    /**
     * Verifie si le message "match" la regex.
     * 
     * @param regex
     * @param message
     * @return true si ca match, false sinon.
     */
    private boolean verifyRegex(String regex, String message) {

        final Pattern pattern = Pattern.compile(regex);
        final Matcher matcher = pattern.matcher(message);

        return matcher.matches();
    }
}

Lorsqu'il lance les tests JUnit depuis Eclipse, John constate qu'ils sont tous rouges, ce qui est tout à fait normal ; c'est le résultat attendu.

John n'a plus qu'à indiquer son avancement et/ou ses remarques sur les Post-It, puis les remettre dans le « sprint backlog ».

De son côté, Julie écrit les tests pour les règles « RG024.x », c'est-à-dire le Post-It bleu « RG024.1 » et le Post-It orange « RG024.2 ». C'est relativement rapide puisqu'il suffit, là encore, de recopier les Post-It.

package fr.chiencopain.boutique.util.encryption;

import static junit.framework.Assert.assertEquals;
import static junit.framework.Assert.assertNotNull;

import org.junit.Before;
import org.junit.Test;

/**
 * Tests de MD5Encryptor : Le systeme peut crypter un mot de passe.
 * 
 * REGLE RG024, RG024.1, RG024.2
 * 
 * @author Julie
 * 
 */
public class MD5EncryptorTest {

    /**
     * Encryptor
     */
    private Encryptor encryptor;

    /**
     * MD5Encryptor
     */
    @Before
    public void doBefore() {
        encryptor = new MD5Encryptor();
    }

    /**
     * Les mots de passe seront cryptes à l'aide de l'algorithme MD5. <br/>
     * 
     * REGLE RG024.1-a <br/>
     * 
     * PARAM password = "football" <br/>
     * RESULT "37b4e2d82900d5e94b8da524fbeb33c0"
     */
    @Test
    public void testEncrypt_RG024_1a() {
        // PARAM
        final String password = "football";
        final String passwordCrypteAttendu = "37b4e2d82900d5e94b8da524fbeb33c0";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * Les mots de passe seront cryptes à l'aide de l'algorithme MD5. <br/>
     * 
     * REGLE RG024.1-b <br/>
     * 
     * PARAM password = "Hello012" <br/>
     * RESULT "00dd4826e068dad5be5e95ef692f62e6"
     */
    @Test
    public void testEncrypt_RG024_1b() {
        // PARAM
        final String password = "Hello012";
        final String passwordCrypteAttendu = "00dd4826e068dad5be5e95ef692f62e6";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * On ne peut pas crypter un mot de passe vide. Si on essaie, ça doit lancer
     * une erreur. <br/>
     * 
     * REGLE RG024.2-a <br/>
     * 
     * PARAM password = "" <br/>
     * RESULT IllegalArgumentException
     */
    @Test(expected = IllegalArgumentException.class)
    public void testEncrypt_RG024_2a() {
        // PARAM
        final String password = "";
        final String passwordCrypteAttendu = "...";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * On ne peut pas crypter un mot de passe vide. Si on essaie, ça doit lancer
     * une erreur. <br/>
     * 
     * REGLE RG024.2-b <br/>
     * 
     * PARAM password = null <br/>
     * RESULT IllegalArgumentException
     */
    @Test(expected = IllegalArgumentException.class)
    public void testEncrypt_RG024_2b() {
        // PARAM
        final String password = null;
        final String passwordCrypteAttendu = "...";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * REGLE RG024.x
     */
    private void doTestEncrypt(String password, String passwordCrypteAttendu) {

        // Appel
        final String passwordCrypte = encryptor.encrypt(password);

        // Tests
        assertNotNull(passwordCrypte);
        assertEquals(passwordCrypteAttendu, passwordCrypte);
    }

}

Comme John, Julie constate que ses tests passent tous au rouge lorsqu'elle lance JUnit depuis Eclipse.

À son tour, Julie met également à jour ses Post-It.

Durant le « sprint », Michel (le chef de projet) consulte régulièrement les métriques du projet. Chez « Green Soft », l'outil d'intégration continue est « Hudson ». Il est configuré pour compiler l'application, à l'aide de Maven, dix minutes après chaque « commit » dans gestionnaire de sources Subversion (SVN). Hudson est également réglé de sorte qu'il génère la documentation (reporting inclus) tous les soirs. Ainsi Michel peut prendre connaissance de l'avancement du projet chaque matin.

Pour commencer, Michel voit que la liste des tags a évolué. Les références, déjà indiquées dans les interfaces, ont été reportées dans les classes de test.

Il constate ensuite que la couverture de code, qui était de zéro pour cent en « T1 », s'est améliorée. Dans l'exemple, Cobertura donne une note de 100 %, ce qui est excellent.

Enfin, Michel peut consulter la liste des tests ayant été écrits. Le rapport indique le nombre et l'emplacement des tests. À la fin de « T2 », tous les nouveaux tests doivent échouer (i.e. être rouges). Ce n'est qu'à la fin de « T3 » qu'ils seront verts.

Une fois de plus, et pour la dernière fois, les développeurs piochent des Post-It dans le « sprint backlog ». Bien entendu, l'illustration va se faire sur les Post-It « RG023 » et « RG024 ». Disons que Julie s'occupe des règles « RG023.x » et que John choisit « RG024.x ». Sébastien, quant à lui, est encore en vacances ou s'occupe d'autres Post-It, etc.

Julie commence donc à coder la classe « DefaultPasswordGenerator » qu'elle avait elle-même initialisée lors de « T1 ». Elle programme ses Post-It dans l'ordre. Tout d'abord, elle doit générer un mot de passe de huit caractères.

package fr.chiencopain.boutique.service.credentials;

import java.util.Random;

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author Julie (T1 et T3)
 * 
 */
public class DefaultPasswordGenerator implements PasswordGenerator {

    /**
     * REGLE RG023, RG023.1, RG023.2
     * 
     * {@inheritDoc}
     */
    public String generate() {

        final StringBuilder sb = new StringBuilder();

        // REGLE RG023.1
        for (int i = 0; i < 8; i++) {
            final char digit = '\0';
            sb.append(digit);
        }

        return sb.toString();
    }

}

Contente d'elle, Julie lance une première batterie de tests. Elle constate que la règle « RG023.1 » a correctement passé le test. Elle peut donc passer à la suite (i.e. la règle « RG023.2 ») qui reste rouge.

Maintenant que le générateur produit un mot de passe de huit digits, Julie doit faire en sorte que les caractères soient choisis parmi les 26 lettres de l'alphabet et/ou les chiffres.

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author Julie (T1 et T3)
 * 
 */
public class DefaultPasswordGenerator implements PasswordGenerator {

    /**
     * Caracteres autorises.
     * 
     * REGLE RG023.2
     */
    private static final String CARACTERES_AUTORISES = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

    /**
     * REGLE RG023, RG023.1, RG023.2
     * 
     * {@inheritDoc}
     */
    public String generate() {

        final StringBuilder sb = new StringBuilder();

        // REGLE RG023.1
        for (int i = 0; i < 8; i++) {
            // REGLE RG023.2
            final char digit = generateOneDigit();
            sb.append(digit);
        }

        return sb.toString();
    }

    /**
     * Selection un caractere au hasard dans la liste des caracteres autorises.
     * 
     * REGLE RG023.2
     * 
     * @return un caractere au hasard.
     */
    private char generateOneDigit() {
        final Random random = new Random();
        final int position = random.nextInt(CARACTERES_AUTORISES.length());
        final char digit = CARACTERES_AUTORISES.charAt(position);
        return digit;
    }
}

Une fois satisfaite, Julie relance les tests. Elle constate, comme prévu, que tous les tests passent au vert.

Julie peut donc, en toute bonne foi, se dire qu'elle a terminé la fonctionnalité. Par acquit de conscience elle lance aussi les tests des fonctionnalités pouvant être impactées par son code (ici, il n'y en a aucune) pour vérifier qu'elle n'a pas engendré de régression.

Si tout est bon, elle peut mettre à jour ses Post-It. Cette fois, contrairement à « T1 » et « T2 », le Post-It ne retourne pas dans le « sprint backlog », mais va dans la colonne des fonctionnalités terminées.

De son côté, John travaille sur « RG024.x ». Contrairement à Julie, qui traite les Post-It par ordre numérique, John préfère commencer par les Post-It techniques (i.e. orange). Il commence donc son développement par le Post-It « RG024.2 ».

package fr.chiencopain.boutique.util.encryption;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024, RG024.1
 * 
 * @author Sebastien, John
 * 
 */
public class MD5Encryptor implements Encryptor {

    /**
     * REGLE RG024, RG024.1
     * 
     * {@inheritDoc}
     */
    public String encrypt(String message) {
        
        // REGLE RG024.2
        if(message == null || message.length() == 0) {
            throw new IllegalArgumentException("Le param 'message' ne peut pas etre vide.");
        }
        
        // TODO Cette methode n'est pas encore developpee. 
        throw new UnsupportedOperationException("Cette methode n'est pas encore developpee.");
    }

}

John lance ses tests. Il constate que les tests « RG024.2-x » passent au vert, mais que les autres tests, pour lesquels il n'a encore rien programmé, restent rouges.

John passe à la suite : le cryptage du mot de passe en MD5.

/**
 * Outil de cryptage.
 * 
 * REGLE RG024, RG024.1
 * 
 * @author Sebastien, John
 * 
 */
public class MD5Encryptor implements Encryptor {

    /**
     * MD5
     * 
     * REGLE RG024.1
     */
    public final static String ALGO_MD5 = "MD55";

    /**
     * REGLE RG024, RG024.1
     * 
     * {@inheritDoc}
     */
    public String encrypt(String message) {

        // REGLE RG024.2
        if (message == null || message.length() == 0) {
            throw new IllegalArgumentException("Le param 'message' ne peut pas etre vide.");
        }

        // REGLE RG024.1
        try {
            final byte[] uniqueKey = message.getBytes();
            final byte[] hash = MessageDigest.getInstance(ALGO_MD5).digest(uniqueKey);

            final StringBuilder sb = new StringBuilder();
            for (int i = 0; i < hash.length; i++) {
                String hex = Integer.toHexString(hash[i]);
                if (hex.length() == 1) {
                    sb.append('0');
                    sb.append(hex.charAt(hex.length() - 1));
                } else {
                    sb.append(hex.substring(hex.length() - 2));
                }
            }
            final String encrypt = sb.toString();
            return encrypt;
        } catch (NoSuchAlgorithmException e) {
            return null;
        }
    }

}

Quand John relance ses tests, il découvre qu'ils sont restés rouges.

Que se passe-t-il ? John, perturbé par la présence de la charmante Vanessa, a fait une faute de frappe. Il a ainsi écrit « MD55 » alors qu'il voulait utiliser l'algorithme « MD5 » avec un seul « 5 ». L'erreur est simple à corriger, mais elle serait très probablement passée inaperçue s'il n'y avait pas eu de test pour la détecter.

Une petite correction, d'une demi- seconde, devrait suffire.

    /**
     * MD5
     * 
     * REGLE RG024.1
     */
    public final static String ALGO_MD5 = "MD5";

Cette fois, les tests deviennent bien (tous) verts. Il s'en est fallu de peu…

John lance les autres tests de l'application pour s'assurer qu'il n'a pas, lui non plus, apporté de régression. Comme tout est bon, il peut légitimement penser que sa fonctionnalité est prête. Il ne reste plus qu'à compléter ses Post-It.

Comme lors des temps précédents, Michel peut consulter la liste des tags du code. Il constate que la liste des choses à faire s'est vidée. Il peut en profiter pour vérifier le bon report des numéros de règle dans le code.

Michel peut également consulter le rapport Surefire (JUnit) qui indique désormais que tous les tests sont OK. À ce stade, il est en droit de penser, puisqu'il a utilisé « 3T » que le développement de l'application est terminé.

En vérifiant le rapport Cobertura, Michel (le chef de projet) constate que le niveau de couverture du code a légèrement baissé.

Immédiatement, un peu inquiet, il clique pour voir les détails. Le rapport lui indique très précisément les points faibles dans le code.

Ici, ce n'est pas difficile de revenir à 100 %. Michel demandera simplement à John de compléter les tests, voire de créer un Post-It technique (orange) additionnel, dès qu'il aura un peu de temps.

Globalement, Michel est très content, car le développement des fonctionnalités a été hyper rapide. En effet, les développeurs ont pu s'appuyer sur les Post-It la plupart du temps et avancer par itérations, en construisant l'application sur des bases de plus en plus solides. Les tests ont permis aux membres de l'équipe d'avoir une confiance élevée dans les codes produits. Les reportings ont permis à Michel de suivre l'avancement des travaux en fournissant des métriques fiables que Michel peut remonter à sa hiérarchie et au client.

Laurent (l'architecte) profite d'un moment de flottement, en fin de « sprint », pour improviser une revue de code. En temps normal, les développeurs s'autoorganisent déjà dans ce sens, mais Laurent souhaite constater/vérifier lui-même l'impact de « 3T » sur la qualité du code. Il a quelques craintes à propos de la méthode. Tout semble si simple qu'il a peur que les développeurs se soient laissé entrainer par cette apparente simplicité pour « bâcler » le travail. En outre, il sait que Michel (le chef de projet) se sent principalement concerné par les tests et la qualité visible de l'application.

Chez « Green Soft », on utilise les logiciels « Check style » et « PMD » pour mesurer la qualité du code. Combinés avec une revue manuelle du code, ces outils fournissent de bonnes indications. Pour sa part, Laurent travaille principalement avec « Check style » directement depuis Eclipse. Michel, quant à lui, préfère consulter les rapports édités depuis Maven.

Laurent s'installe donc avec les développeurs, à tour de rôle, et active les vérifications « Check style » lorsqu'elles n'étaient pas déjà activées. En tout, il ne trouve qu'une vingtaine de petites violations aux règles « Check Style » de « Green Soft » (mots clés dans le mauvais ordre, paramètres non déclarés finaux, Javadoc incomplète, etc.), qu'il fait corriger directement par les développeurs concernés. C'est plutôt pas mal.

Globalement, Laurent n'a rien à dire, à part les détails indiqués ci-dessus, car le principe d'écriture de « 3T » conduit naturellement à écrire du code propre, à proscrire les duplications, à avoir une forte couverture de test, à séparer les responsabilités, à respecter les standards, etc. En fait, puisque « 3T » apporte un processus simple où les étapes sont décomposées et guident les développeurs, ces derniers peuvent se concentrer sur la qualité de leurs travaux, ce qui n'est pas toujours le cas dans des projets classiques.

Arrivant en fin de projet (et/ou de « sprint »), Bernard (le responsable de la Qualif) doit s'assurer que le produit fabriqué est conforme aux attentes du client. Il a reçu les versions successives du cahier des charges et se tient prêt à vérifier les livrables.

Par habitude, Bernard sait qu'il va rejeter la première (et même les suivantes) tentative de livraison après seulement quelques heures de test. En effet, il trouve toujours quelque chose à redire sur la conformité du produit. Pour se faire, il teste scrupuleusement tous les points spécifiés dans le cahier des charges.

Le plus dur de son travail consiste à mettre en place les jeux de test nécessaires, à dérouler lesdits tests, puis à consigner les anomalies dans Mantis (l'outil de « bug tracking » open source utilisé par « Green Soft »). D'ailleurs, Bernard en a ras le bol de créer des fiches Mantis à longueur de journée. Il aimerait bien se concentrer sur la mise en place de tests puissants, allant bien au-delà des besoins exprimés, et qui contribueraient à asseoir la réputation de « Green Soft ».

Quelle va donc être sa surprise lorsque, après avoir lancé ses batteries de tests, Bernard ne détecte aucune anomalie ? Ça n'est jamais arrivé jusque-là. Il croit d'abord à une mauvaise manipulation et relance entièrement sa série de tests. Mais là encore, rien à signaler ! Interloqué, il appose son tampon de validation et envoie un email de félicitations au chef de projet (Michel) et au DSI.

En réalité, lorsque « 3T » est appliqué sur un projet, son principe premier veut que les développements soient réalisés en partant des tests, eux-mêmes écrits à partir du cahier des charges. Or il est probable que les tests écrits par l'équipe de développement soient très proches de ceux de Bernard.

Claire (la cliente) a une liste de nouvelles demandes qu'elle souhaite voir développées en « v2 ». Dans le cadre de cet article, on ne va évidemment illustrer que les besoins liés à la génération et le cryptage de mot de passe, pour faire suite aux chapitres précédents.

Tout d'abord, Claire souhaite que les mots de passe générés soient de taille variable. Pour des raisons de sécurité, elle veut également que les mots de passe générés ne soient plus uniquement composés de lettres et/ou de chiffres, mais qu'ils contiennent aussi des caractères de ponctuation. Enfin, Claire a découvert, en écoutant l'excellent podcast « Techno IT »podcast Techno IT que le cryptage « SHA-1 » a remplacé le « MD5 ». Bien qu'elle n'ait pas compris les raisons de ce changement, elle souhaite que « Green Soft » l'accompagne dans ce sens.

De nouveau, Michel (le chef de projet) réunit son équipe pour analyser le nouveau cahier des charges. Après discussion avec Claire, l'équipe part sur les Post-It suivants. Les Post-It « 023.3 », « 023.4 » et « 024.3 » sont nouveaux.

De manière générale, quand le sujet d'un Post-It évolue, on peut soit mettre à jour le Post-It, en en gérant les versions successives, soit « annuler » le Post-It et le remplacer par un nouveau. C'est donc ce second choix qui a été retenu chez « Green Soft ». Les Post-It « 023.1 », « 023.2 » et « 024.1 » sont marqués comme annulés.

Les Post-It (fonctionnels) jaunes de la « v1 », quant à eux, sont simplement remplacés par de nouveaux Post-It jaunes pour la « v2 ». Les nouveaux Post-It sont prêts à suivre un nouveau « processus 3T » couplé à Scrum.

En une année, l'équipe de développement a beaucoup évolué. Tout d'abord, Laurent (l'architecte) et Julie se sont mariés. Une grande fête a été organisée dans les bureaux de « Green Soft » pour célébrer l'événement. Une chose en entrainant une autre, Julie est désormais en congé maternité et ne participera donc pas au développement des évolutions de « la boutique du Chien-Copain ». John (le développeur barbu) travaille désormais en Belgique, en tant que « team leader » sur un projet du gouvernement dont « Green Soft » a remporté l'appel d'offres.

De l'équipe initiale, il ne reste donc plus que Sébastien. Ce dernier a rapidement été rejoint par William et Nathalie, puis par Luc un peu plus tard.

William et Nathalie reviennent d'un projet Web, pris en charge par « Green Soft », chez un opérateur de télécom, où ils travaillaient en « pair programming » dans le cadre d'une méthodologie « XP ». Luc, quant à lui, a été remercié d'un autre projet dans lequel il s'ennuyait. Michel, avec qui il était resté en contact, lui a proposé de rejoindre l'équipe pour découvrir les bienfaits de « 3T » et redécouvrir des bases de travail motivantes.

Un point intéressant des TDD, est la capacité de prise en main rapide que la méthode offre aux nouveaux développeurs du projet. En effet, puisque les tests sont documentés et guident le code source des programmes, il suffit de repartir des tests pour comprendre ce que fait le programme. Les développeurs peuvent donc s'appuyer sur leurs compétences techniques pour s'immerger dans le fonctionnel de l'application. En outre, puisque « 3T » s'inspire directement du cahier des charges, la démarche est d'autant plus simplifiée.

Dans l'histoire, Sébastien est le seul développeur restant à posséder une connaissance à la fois technique et fonctionnelle de « la Boutique du Chien-Copain ». Son rôle ne va pas être de transmettre cette connaissance, mais de guider les nouveaux membres de l'équipe à travers les TDD et « 3T » pour qu'ils accèdent progressivement au même niveau de compétence (cf. conversations en annexes).

Sans surprise, puisque c'est l'objet de cet article, les développements de la « v2 » de la boutique en ligne vont suivre les trois temps de « 3T ».

IV-C-1. Les interfaces (T1)▲

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023
 * 
 * @author Julie
 * 
 */
public interface PasswordGenerator {

    /**
     * Genere un mot de passe.
     * 
     * REGLE RG023
     * 
     * @return Un mot de passe genere.
     */
    String generate();
}

/**
 * Outil de cryptage.
 * 
 * REGLE RG024
 * 
 * @author Sebastien
 * 
 */
public interface Encryptor {
    /**
     * Crypte le message passe en parametre. <br/>
     * 
     * REGLE RG024
     * 
     * @param message
     *            Le message a crypter.
     * @return une version cryptee du message.
     */
    String encrypt(String message);
}

package fr.chiencopain.boutique.service.credentials;

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023
 * 
 * @author Sébastien
 * 
 */
public class AdvancePasswordGenerator implements PasswordGenerator {
    /**
     * REGLE RG023
     * 
     * {@inheritDoc}
     */
    public final String generate() {
        // TODO Cette methode n'est pas encore developpee.
        throw new UnsupportedOperationException("Cette methode n'est pas encore developpee.");
    }
}

package fr.chiencopain.boutique.util.encryption;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024
 * 
 * @author Sebastien
 * 
 */
public class Sha1Encryptor implements Encryptor {

    /**
     * REGLE RG024
     * 
     * {@inheritDoc}
     */
    public final String encrypt(final String message) {
        // TODO Cette methode n'est pas encore developpee.
        throw new UnsupportedOperationException("Cette methode n'est pas encore developpee.");
    }
}

IV-C-2. Les tests (T2)▲

Durant ce deuxième temps, disons que Nathalie et William vont écrire, en « pair programming », les tests de « RG023 » et que Luc va s'occuper de « RG024 ».

Lorsqu'on écrit du code pour la première fois, c'est relativement simple puisqu'il suffit de partir de zéro. On est libre d'aller dans la direction qui nous intéresse sans contrainte. En revanche, lorsqu'on fait évoluer du code, comme c'est le cas ici, par ajout de nouvelles règles, il faut s'intégrer dans l'existant. L'objectif est de s'inspirer de ce que les développeurs précédents ont réalisé, tout en complétant/modifiant le code. Dans le cas présent, en ce qui concerne les tests unitaires et l'addition de nouveaux tests qui ressemblent aux anciens, cela se traduit par un peu de réorganisation, et notamment par de la factorisation et de l'héritage.

Conformément aux Post-It, certains tests sont annulés. Ils devraient donc être supprimés du code. Toutefois, dans la mesure où de nouvelles classes ont été prévues pour accueillir les évolutions, et que ces dernières (programmées ainsi) ne sont pas incompatibles avec l'existant, l'équipe décide de tout conserver. En outre, cela m'arrange pour l'illustration de cet article.

Nathalie et William vont donc créer une classe de test abstraite et réorganiser la classe existante pour qu'elle utilise la nouvelle classe.

AbstractPasswordGeneratorTest

Sélectionnez

package fr.chiencopain.boutique.service.credentials;

import java.util.regex.Matcher;
import java.util.regex.Pattern;

/**
 * 
 * @author Nathalie et William
 * 
 */
public abstract class AbstractPasswordGeneratorTest {
    /**
     * Verifie si le message "match" la regex.
     * 
     * @param regex
     *            la regex de controle.
     * @param message
     *            le message a valider.
     * @return true si ca match, false sinon.
     */
    protected final boolean verifyRegex(final String regex, final String message) {

        final Pattern pattern = Pattern.compile(regex);
        final Matcher matcher = pattern.matcher(message);

        return matcher.matches();
    }
}

DefaultPasswordGeneratorTest (modifiée)

Sélectionnez

/**
 * Tests de DefaultPasswordGenerator.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author John, puis Nathalie et William (v2)
 * 
 */
public class DefaultPasswordGeneratorTest extends AbstractPasswordGeneratorTest {
    /**
     * PasswordGenerator
     */
    private PasswordGenerator passwordGenerator;

    /**
     * DefaultPasswordGenerator
     */
    @Before
    public final void doBefore() {
        passwordGenerator = new DefaultPasswordGenerator();
    }

    /**
     * Le mot de passe genere sera compose de 8 digits. <br/>
     * 
     * REGLE RG023.1 <br/>
     * 
     * RESULT : length = 8 <br/>
     * 
     * Exemple a : football <br/>
     * Exemple b : voitures
     */
    @Test
    public final void testGenerate_RG023_1() {
        // Param
        final int tailleAttendue = 8;

        // Appel
        final String password = passwordGenerator.generate();

        // Tests
        assertNotNull(password);
        assertEquals(tailleAttendue, password.length());
    }

    /**
     * Le mot de passe genere sera compose des 26 lettres de l'alphabet, en
     * majuscules et/ou en minuscules, et des chiffres de 0 à 9. <br/>
     * 
     * REGLE RG023.2 <br/>
     * 
     * Exemple a : abcd1234 <br/>
     * Exemple b : Hello012
     */
    @Test
    public final void testGenerate_RG023_2() {

        final String lettresAutoriseesRegex = "[a-zA-Z0-9]+";

        // Appel
        final String password = passwordGenerator.generate();

        // Tests
        assertNotNull(password);
        assertTrue(verifyRegex(lettresAutoriseesRegex, password));

    }
}

AdvancePasswordGeneratorTest

Sélectionnez

package fr.chiencopain.boutique.service.credentials;

import static junit.framework.Assert.assertNotNull;
import static junit.framework.Assert.assertTrue;

import org.junit.Before;
import org.junit.Test;

/**
 * Tests de AdvancePasswordGenerator.
 * 
 * REGLE RG023, RG023.3, RG023.4
 * 
 * @author Nathalie et William
 * 
 */
public class AdvancePasswordGeneratorTest extends AbstractPasswordGeneratorTest {
    /**
     * PasswordGenerator
     */
    private PasswordGenerator passwordGenerator;

    /**
     * AdvancePasswordGenerator
     */
    @Before
    public final void doBefore() {
        passwordGenerator = new AdvancePasswordGenerator();
    }

    /**
     * Le mot de passe genere sera compose de 6 à 10 digits. <br/>
     * 
     * REGLE RG023.3 <br/>
     * Test en boucle a cause du comportement aleatoire. <br/>
     * 
     * PARAM nbDigitMin = 6 <br/>
     * PARAM nbDigitMax = 10
     * 
     */
    @Test
    public final void testGenerate_RG023_3_boucle() {
        // Param
        final int nbDigitMin = 6;
        final int nbDigitMax = 10;

        // Boucle car on cherche a tester plein de cas.
        for (int i = 0; i < 1000; i++) {
            // Appel
            final String password = passwordGenerator.generate();

            // Tests
            assertNotNull(password);
            final int passwordLength = password.length();
            assertTrue(nbDigitMin <= passwordLength);
            assertTrue(passwordLength <= nbDigitMax);
        }
    }

    /**
     * Le mot de passe genere sera compose des 26 lettres en majuscules et/ou en
     * minuscules, des chiffres et des ponctuations simples ou doubles. <br/>
     * 
     * REGLE RG023.2 <br/>
     * 
     * Exemple a : abcd1234 <br/>
     * Exemple b : Hello012
     */
    @Test
    public final void testGenerate_RG023_4() {

        // Param
        // regex : [a-zA-Z0-9,.'";:!?\-]+
        final String lettresAutoriseesRegex = "[a-zA-Z0-9,.'\";:!?\\-]+"; 

        // Appel
        final String password = passwordGenerator.generate();

        // Tests
        assertNotNull(password);
        assertTrue(verifyRegex(lettresAutoriseesRegex, password));

    }
}

Durant le développement, Nathalie et William doivent vérifier qu'ils ne modifient pas le comportement des anciens tests. Bien entendu, après « T2 », les nouveaux tests doivent échouer (i.e. être rouges).

Luc va adopter la même stratégie pour les nouveaux tests dont il s'occupe.

AbstractEncryptorTest

Sélectionnez

package fr.chiencopain.boutique.util.encryption;

import static junit.framework.Assert.assertEquals;
import static junit.framework.Assert.assertNotNull;

import org.junit.Test;

/**
 * REGLE RG024.2
 
 * @author Luc
 * 
 */
public abstract class AbstractEncryptorTest {
    /**
     * Encryptor
     */
    protected Encryptor encryptor;

    /**
     * REGLE RG024.x
     * 
     * @param password
     *            Le mot de passe en clair.
     * @param passwordCrypteAttendu
     *            Le mot de passe crypte attendu.
     */
    protected final void doTestEncrypt(final String password, final String passwordCrypteAttendu) {

        // Appel
        final String passwordCrypte = encryptor.encrypt(password);

        // Tests
        assertNotNull(passwordCrypte);
        assertEquals(passwordCrypteAttendu, passwordCrypte);
    }

    /**
     * On ne peut pas crypter un mot de passe vide. Si on essaie, ça doit lancer
     * une erreur. <br/>
     * 
     * REGLE RG024.2-a <br/>
     * 
     * PARAM password = "" <br/>
     * RESULT IllegalArgumentException
     */
    @Test(expected = IllegalArgumentException.class)
    public final void testEncrypt_RG024_2a() {
        // PARAM
        final String password = "";
        final String passwordCrypteAttendu = "...";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * On ne peut pas crypter un mot de passe vide. Si on essaie, ça doit lancer
     * une erreur. <br/>
     * 
     * REGLE RG024.2-b <br/>
     * 
     * PARAM password = null <br/>
     * RESULT IllegalArgumentException
     */
    @Test(expected = IllegalArgumentException.class)
    public final void testEncrypt_RG024_2b() {
        // PARAM
        final String password = null;
        final String passwordCrypteAttendu = "...";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }
}

MD5EncryptorTest (modifiée)

Sélectionnez

/**
 * Tests de MD5Encryptor : Le systeme peut crypter un mot de passe.
 * 
 * REGLE RG024, RG024.1, RG024.2
 * 
 * @author Julie, puis modifiée par Luc en v2.
 * 
 */
public class MD5EncryptorTest extends AbstractEncryptorTest {

    /**
     * MD5Encryptor
     */
    @Before
    public final void doBefore() {
        encryptor = new MD5Encryptor();
    }

    /**
     * Les mots de passe seront cryptes à l'aide de l'algorithme MD5. <br/>
     * 
     * REGLE RG024.1-a <br/>
     * 
     * PARAM password = "football" <br/>
     * RESULT "37b4e2d82900d5e94b8da524fbeb33c0"
     */
    @Test
    public final void testEncrypt_RG024_1a() {
        // PARAM
        final String password = "football";
        final String passwordCrypteAttendu = "37b4e2d82900d5e94b8da524fbeb33c0";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }

    /**
     * Les mots de passe seront cryptes a l'aide de l'algorithme MD5. <br/>
     * 
     * REGLE RG024.1-b <br/>
     * 
     * PARAM password = "Hello012" <br/>
     * RESULT "00dd4826e068dad5be5e95ef692f62e6"
     */
    @Test
    public final void testEncrypt_RG024_1b() {
        // PARAM
        final String password = "Hello012";
        final String passwordCrypteAttendu = "00dd4826e068dad5be5e95ef692f62e6";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }
}

Sha1EncryptorTest

Sélectionnez

package fr.chiencopain.boutique.util.encryption;

import org.junit.Before;
import org.junit.Test;

/**
 * Tests de Sha1Encryptor : Le systeme peut crypter un mot de passe.
 * 
 * REGLE RG024, RG024.2, RG024.3
 * 
 * @author Luc
 * 
 */
public class Sha1EncryptorTest extends AbstractEncryptorTest {
    /**
     * Sha1Encryptor
     */
    @Before
    public final void doBefore() {
        encryptor = new Sha1Encryptor();
    }
    
    
    /**
     * Le système doit crypter les mots de passe en SHA-1.  <br/>
     * 
     * REGLE RG024.3 <br/>
     * 
     * PARAM password = "football" <br/>
     * RESULT "2d27b62c597ec858f6e7b54e7e58525e6a95e6d8"
     */
    @Test
    public final void testEncrypt_RG024_3() {
        // PARAM
        final String password = "football";
        final String passwordCrypteAttendu = "2d27b62c597ec858f6e7b54e7e58525e6a95e6d8";

        // Appel
        doTestEncrypt(password, passwordCrypteAttendu);
    }
}

Finalement, les anciens tests doivent rester verts et les nouveaux tests, conçus pour échouer au sens de « 3T », doivent être rouges, ce que les développeurs peuvent vérifier directement depuis Eclipse.

IV-C-3. Les développements (T3)▲

Les Post-It arrivent désormais dans le dernier temps pour cette « v2 » et le plus gros du travail a déjà été réalisé en « v1 », un an auparavant. Les nouveaux développements vont pouvoir s'appuyer allègrement sur l'existant, en plus des tests qui vont guider l'écriture. Comme pour l'ajout de tests lors de « T2 », les nouveaux codes (en « T3 ») vont entrainer un peu de réorganisation.

Disons que Luc prend en charge le développement de « RG023 » et que Sébastien s'occupe de « RG024 ».

Luc s'inspire largement des tests, pour lesquels l'équipe a identifié un besoin de « refactoring », laissant supposer que cette action aura une réponse similaire dans le cadre du développement final. Luc crée donc une classe abstraite et adapte les anciens codes. Enfin, il code la classe qui va générer des mots de passe avec les nouvelles règles.

AbstractPasswordGenerator

Sélectionnez

package fr.chiencopain.boutique.service.credentials;

import java.util.Random;

/**
 * REGLE RG023.2
 * 
 * @author Luc
 * 
 */
public abstract class AbstractPasswordGenerator implements PasswordGenerator {

    /**
     * Selection un caractere au hasard dans la liste des caracteres autorises.
     * 
     * REGLE RG023.2
     * 
     * @param caracteresAutorises
     *            les caracteres qui sont autorises.
     * @return un caractere au hasard.
     */
    protected final char generateOneDigit(final String caracteresAutorises) {
        final Random random = new Random();
        final int position = random.nextInt(caracteresAutorises.length());
        final char digit = caracteresAutorises.charAt(position);
        return digit;
    }
}

DefaultPasswordGenerator (modifiée)

Sélectionnez

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023, RG023.1, RG023.2
 * 
 * @author Julie (T1 et T3), Luc en v2.
 * 
 */
public class DefaultPasswordGenerator extends AbstractPasswordGenerator implements PasswordGenerator {

    /**
     * Caracteres autorises.
     * 
     * REGLE RG023.2
     */
    private static final String CARACTERES_AUTORISES = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";

    /**
     * REGLE RG023, RG023.1, RG023.2
     * 
     * {@inheritDoc}
     */
    public final String generate() {

        final StringBuilder sb = new StringBuilder();

        // REGLE RG023.1
        final int nombreDigit = 8;
        for (int i = 0; i < nombreDigit; i++) {
            // REGLE RG023.2
            final char digit = generateOneDigit();
            sb.append(digit);
        }

        return sb.toString();
    }

    /**
     * Selection un caractere au hasard dans la liste des caracteres autorises.
     * 
     * REGLE RG023.2
     * 
     * @return un caractere au hasard.
     */
    private char generateOneDigit() {
        return generateOneDigit(CARACTERES_AUTORISES);
    }
}

AdvancePasswordGenerator

Sélectionnez

package fr.chiencopain.boutique.service.credentials;

import java.util.Random;

/**
 * Outil de generation de mot de passe.
 * 
 * REGLE RG023
 * 
 * @author Sébastien (T1), Luc (T3)
 * 
 */
public class AdvancePasswordGenerator extends AbstractPasswordGenerator implements PasswordGenerator {
    
    /**
     * Caracteres autorises.
     * 
     * lettres : a-z et A-Z <br/>
     * chiffres : 0-9 <br/>
     * Ponctuations : ,.'";:!- (virgule, point, apostrophe, guillemet,
     * point-virgule, deux-point, point d'exclamation, point d'interrogation,
     * tiret)
     * 
     * REGLE RG023.4
     */
    private static final String CARACTERES_AUTORISES = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,.'\";:!?-";

    
    /**
     * REGLE RG023, RG023.3, RG023.4
     * 
     * {@inheritDoc}
     */
    public final String generate() {
        final StringBuilder sb = new StringBuilder();
        
        
        final Random random = new Random();
        final int nb = random.nextInt(5);
        // REGLE RG023.1
        final int nombreDigit = 6 + nb;
        for (int i = 0; i < nombreDigit; i++) {
            // REGLE RG023.4
            final char digit = generateOneDigit(CARACTERES_AUTORISES);
            sb.append(digit);
        }
        
        return sb.toString();
    }
}

Pour des raisons purement techniques, Sébastien commence par ajouter des constantes (non prévues) dans l'interface. Il crée ensuite une classe abstraite pour factoriser une partie des traitements, et adapte la classe spécifique au cryptage MD5 en fonction. Il n'a plus, finalement, qu'à compléter la nouvelle classe pour SHA-1, ce qui ne prend que quelques instants.

Encryptor (modifiée)

Sélectionnez

/**
 * Outil de cryptage.
 * 
 * REGLE RG024
 * 
 * @author Sebastien
 * 
 */
public interface Encryptor {
    /**
     * MD5
     */
    String ALGO_MD5 = "MD5";
    
    /**
     * SHA-1
     */
    String ALGO_SHA1 = "SHA-1";

    /**
     * Crypte le message passe en parametre. <br/>
     * 
     * REGLE RG024
     * 
     * @param message
     *            Le message a crypter.
     * @return une version cryptee du message.
     */
    String encrypt(String message);
}

AbstractSimpleEncryptor

Sélectionnez

package fr.chiencopain.boutique.util.encryption;

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024
 * 
 * @author Sebastien
 * 
 */
public abstract class AbstractSimpleEncryptor implements Encryptor {

    /**
     * REGLE RG024
     * 
     * {@inheritDoc}
     */
    protected final String doEncrypt(final String message, final String algo) {
        // REGLE RG024.2
        if (message == null || message.length() == 0) {
            throw new IllegalArgumentException("Le param 'message' ne peut pas etre vide.");
        }

        // REGLE RG024.1, RG024.3
        try {
            final byte[] uniqueKey = message.getBytes();
            final byte[] hash = MessageDigest.getInstance(algo).digest(uniqueKey);

            final StringBuilder sb = new StringBuilder();
            for (int i = 0; i < hash.length; i++) {
                String hex = Integer.toHexString(hash[i]);
                if (hex.length() == 1) {
                    sb.append('0');
                    sb.append(hex.charAt(hex.length() - 1));
                } else {
                    sb.append(hex.substring(hex.length() - 2));
                }
            }
            final String encrypt = sb.toString();
            return encrypt;
        } catch (NoSuchAlgorithmException e) {
            return null;
        }
    }
}

MD5Encryptor (modifiée)

Sélectionnez

/**
 * Outil de cryptage.
 * 
 * REGLE RG024, RG024.1
 * 
 * @author Sebastien, John, Sebastien (v2)
 * 
 */
public class MD5Encryptor extends AbstractSimpleEncryptor implements Encryptor {

    /**
     * MD5
     * 
     * REGLE RG024.1
     */
    public static final String ALGO_CRYPTAGE = ALGO_MD5;

    /**
     * REGLE RG024, RG024.1
     * 
     * {@inheritDoc}
     */
    public final String encrypt(final String message) {

        return doEncrypt(message, ALGO_CRYPTAGE);
    }
}

Sha1Encryptor

Sélectionnez

package fr.chiencopain.boutique.util.encryption;

/**
 * Outil de cryptage.
 * 
 * REGLE RG024, RG024.2, RG024.3
 * 
 * @author Sebastien
 * 
 */
public class Sha1Encryptor extends AbstractSimpleEncryptor implements Encryptor {
    
    /**
     * SHA-1
     * 
     * REGLE RG024.3
     */
    public static final String ALGO_CRYPTAGE = ALGO_SHA1;
    
    /**
     * REGLE RG024.3
     * 
     * {@inheritDoc}
     */
    public final String encrypt(final String message) {
        
        return doEncrypt(message, ALGO_CRYPTAGE);
    }
}

Un des grands avantages de « 3T », et plus particulièrement du travail divisé en temps, est de permettre aux développeurs de se concentrer sur des petites tâches. Par conséquent, durant le troisième temps, ils peuvent consacrer de l'énergie sur du « refactoring continu » et ainsi avoir une qualité qui augmente au fur et à mesure.

Maintenant que tous les développements sont réalisés, tous les nouveaux tests doivent passer au vert. On doit bien penser à vérifier que les anciens tests, limités aux tests non annulés, continuent d'être verts.

IV-C-4. Les Post-It scannés▲

Michel (le chef de projet) va être content en fin de projet. Les rapports fournissent des métriques excellentes. Évidemment, le rapport Surefire résumant les tests JUnit indique 100 % de réussite. Le contrat est donc rempli.

S'étant déjà fait surprendre l'an passé, lors de la phase de qualification de la « v1 », Bernard a préparé son affaire. Il a suivi le développement du coin de l'œil pour être prêt le jour J. Il a donc mis en place une batterie de tests conforme au cahier des charges, mais il a ajouté un ensemble de critères qualité, en accord avec Michel (le chef de projet), pour aller bien plus loin que les demandes du client. Ainsi le projet sera tiré vers le haut.

Sans grosse surprise, désormais, la qualification se passe sans encombre. Bernard ne trouve à redire que sur certains détails relatifs aux nouveaux critères avancés qu'il a ajoutés. C'est tellement négligeable, et hors périmètre, qu'il accepte la livraison sans discuter plus que ça.

Dans cette partie de l'article, je propose plusieurs discussions fictives entre les acteurs de l'histoire pour comprendre leurs choix.

VII-A-1. Le goût de « 3T »▲

VII-A-2. Les Post-It de « 3T » collent à Scrum▲

VII-A-3. Ragot « 3T »▲

VII-A-4. Le choc de « 3T »▲

VII-A-5. Motivation▲

Pour écrire cet article, j'ai créé un nouveau projet Maven 3 en écrivant le fichier pom (proposé ci-dessous) dans le dossier « boutique-chien-copain ».

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>fr.chien-copain</groupId>
    <artifactId>boutique</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>jar</packaging>

    <name>Boutique du Chien-Copain</name>
    <description>Projet de la Boutique du Chien-Copain</description>
    <url>http://www.thierryler.com</url>

    <licenses>
        <license>
            <name>Copyright ©1995-2011 thierryler.com et Copyright ©2011 Developpez.com</name>
            <comments>Les sources présentés sur cette page sont [..] Cette page est déposée à la SACD.</comments>
        </license>
    </licenses>

    <developers>
        <!-- Michel -->
        <developer>
            <name>Michel</name>
            <roles>
                <role>Chef de projet</role>
            </roles>
            <organization>Green Soft</organization>
        </developer>

        <!-- Laurent -->
        <developer>
            <name>Laurent</name>
            <roles>
                <role>Architecte</role>
                <role>Developpeur</role>
            </roles>
            <organization>Green Soft</organization>
        </developer>

        <!-- Julie -->
        <developer>
            <name>Julie</name>
            <roles>
                <role>Developpeur</role>
            </roles>
            <organization>Green Soft</organization>
        </developer>

        <!-- Sébastien -->
        <developer>
            <name>Sébastien</name>
            <roles>
                <role>Developpeur</role>
            </roles>
            <organization>Green Soft</organization>
        </developer>

        <!-- John -->
        <developer>
            <name>John</name>
            <roles>
                <role>Developpeur</role>
            </roles>
            <organization>Green Soft</organization>
        </developer>
    </developers>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven-compiler-plugin.version>2.3.1</maven-compiler-plugin.version>
        <junit.version>4.8.1</junit.version>
        <maven-site-plugin.version>3.0-beta-3</maven-site-plugin.version>
        <maven-javadoc-plugin.version>2.8</maven-javadoc-plugin.version>
        <maven-checkstyle-plugin.version>2.7</maven-checkstyle-plugin.version>
        <maven-pmd-plugin.version>2.5</maven-pmd-plugin.version>
        <maven-jxr-plugin.version>2.3</maven-jxr-plugin.version>
        <taglist-maven-plugin.version>2.4</taglist-maven-plugin.version>
        <cobertura-maven-plugin.version>2.5.1</cobertura-maven-plugin.version>
        <maven-surefire-plugin.version>2.9</maven-surefire-plugin.version>
        <maven-surefire-report-plugin>2.9</maven-surefire-report-plugin>
        <log4j.version>1.2.13</log4j.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <!-- JUnit -->
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>${junit.version}</version>
                <scope>test</scope>
            </dependency>

            <!-- JAX WS RT -->
            <dependency>
                <groupId>com.sun.xml.ws</groupId>
                <artifactId>jaxws-rt</artifactId>
                <version>${jaxws-rt.version}</version>
            </dependency>

            <!-- log4j -->
            <dependency>
                <groupId>log4j</groupId>
                <artifactId>log4j</artifactId>
                <version>${log4j.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <finalName>Boutique du Chien-Copain</finalName>

        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven-compiler-plugin.version}</version>
                <configuration>
                    <source>1.5</source>
                    <target>1.5</target>
                    <encoding>${project.build.sourceEncoding}</encoding>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-site-plugin</artifactId>
                <version>${maven-site-plugin.version}</version>
            </plugin>
            
            <!-- Surefire -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${maven-surefire-plugin.version}</version>
            </plugin>
        </plugins>
    </build>


    <reporting>
        <plugins>
            <!-- javadoc -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <version>${maven-javadoc-plugin.version}</version>
            </plugin>

            <!-- checkstyle -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-checkstyle-plugin</artifactId>
                <version>${maven-checkstyle-plugin.version}</version>
                <!-- <configuration> <configLocation>checkstyle.xml</configLocation> 
                    </configuration> -->
            </plugin>
            
            <!-- PMD -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-pmd-plugin</artifactId>
                <version>${maven-pmd-plugin.version}</version>
            </plugin>

            <!-- JXR : pour lier les sources -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jxr-plugin</artifactId>
                <version>${maven-jxr-plugin.version}</version>
            </plugin>

            <!-- taglist -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>taglist-maven-plugin</artifactId>
                <version>${taglist-maven-plugin.version}</version>
                <configuration>
                    <tagListOptions>
                        <tagClasses>
                            <tagClass>
                                <displayName>Todo Work</displayName>
                                <tags>
                                    <tag>
                                        <matchString>todo</matchString>
                                        <matchType>ignoreCase</matchType>
                                    </tag>
                                    <tag>
                                        <matchString>FIXME</matchString>
                                        <matchType>exact</matchType>
                                    </tag>
                                </tags>
                            </tagClass>
                            <tagClass>
                                <displayName>Regles</displayName>
                                <tags>
                                    <tag>
                                        <matchString>REGLE</matchString>
                                        <matchType>ignoreCase</matchType>
                                    </tag>
                                </tags>
                            </tagClass>
                        </tagClasses>
                    </tagListOptions>
                </configuration>
            </plugin>

            <!-- Cobertura : couverture de code -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>cobertura-maven-plugin</artifactId>
                <version>${cobertura-maven-plugin.version}</version>
            </plugin>
            
            <!-- Surefire (junit) -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-report-plugin</artifactId>
                <version>${maven-surefire-report-plugin}</version>
            </plugin>

        </plugins>
    </reporting>
</project>

Ensuite, en ligne de commande, dans le répertoire « boutique-chien-copain », j'ai fabriqué la structure du projet Eclipse à l'aide de la commande Maven suivante.

mvn clean install eclipse:eclipse

La commande crée en particulier le dossier « target » et les fichiers Eclipse « .classpath » et « .project ». Il ne reste plus qu'à importer le projet dans Eclipse (via le menu « File>Import>General>Existing Projects into Workspace »). Maintenant on peut travailler.

Le « dashboard » est un outil visuel de Scrum, qui ressemble aux illustrations ci-dessous. Le « dashboard Scrum » se présente le plus souvent sous la forme d'un tableau avec trois colonnes, dans lesquelles les développeurs collent des Post-It. Chaque Post-It correspond, grosso modo, à une tâche à accomplir. Les colonnes indiquent si la tâche est en attente de traitement, en cours de traitement ou terminée. En fonction de l'avancée de l'équipe, les Post-It changent progressivement de colonne.

Normalement, en début de projet (ou de « sprint ») tous les Post-It sont dans la colonne de gauche (« sprint backlog »). À la fin du projet, tous les Post-It doivent être dans la colonne de droite. Durant les développements, les Post-It transitent, en toute logique, par la colonne centrale.

Dans cet article, les développeurs de « Green Soft », mélangent les Post-It de Scrum et les Post-It de « 3T ».

Dans cet article, je m'autorise beaucoup de libertés vis-à-vis de Scrum et des TDD. Dans Scrum, les Post-It vont du « sprint backlog » (c'est-à-dire la colonne de gauche du « dashboard ») vers la colonne de droite en fonction de la réalisation des tâches. Un « sprint » est une durée (généralement 2 ou 3 semaines) durant laquelle l'équipe va se concentrer sur un ensemble de Post-It bien identifiés.

Dans le cadre de « 3T », les Post-It doivent traverser trois fois le « dashboard » durant le sprint. Chaque passage correspond à un temps de « 3T » : écriture des interfaces, écriture des tests et écriture du code. J'entends déjà les puristes qui crient au scandale. Gardons à l'esprit que ce n'est qu'une proposition.

Pour finir cet article, je me permets une petite analyse personnelle à propos de la confiance. Vous souvenez-vous lorsque votre médecin vous affirmait que « ça n'allait pas faire mal » juste avant de vous infliger une piqure ? Sacré menteur !… Ma mère avait l'habitude de me dire de ne « jamais faire confiance à personne sauf à ta maman » et j'ajoute qu'il ne faut jamais faire confiance à quelqu'un qui vous demande de lui faire confiance.

Comment cela se traduit-il en informatique et plus particulièrement dans le cadre du développement logiciel ? À l'intérieur d'une application, cela implique l'utilisation de techniques de défense (copie de défense, assertion, etc.), mais ce n'est pas l'objet de cet article. Dans la communication, c'est encore plus simple : il ne faut jamais faire confiance à un développeur ou à une équipe et encore moins à un logiciel. Ce que je demande à mes clients, c'est de ne jamais croire à mes promesses (je n'en fais jamais), mais, au contraire, de toujours exiger des preuves.

Plus concrètement, et sous réserve qu'on m'en donne les moyens, je crois que « 3T » est une bonne piste pour arriver à cet objectif. Avec « 3T », on écrit d'abord les tests qui prouveront au client que le produit en création sera conforme au cahier des charges. J'insiste sur le fait que les tests doivent être écrits en amont, et non après les développements comme c'est encore trop souvent le cas malheureusement (car cela favorise la multiplication de tests de complaisance). En procédant de cette manière, je crois qu'une équipe gagne bien plus que de la « confiance » ; elle acquiert de la « crédibilité »…