Démarche TDD – Une première tentative – Part 1

Démarche TDD – Une première tentative – Part 2

Cette dernière partie va se concentrer sur une autre utilisation des tests unitaires

Contrainte supplémentaire

Notre petite implémentation de l’équilibirum a été adoptée pour être incluse dans un projet en production. Super, il est toujours agréable de voir son travail utilisé. Par contre, dans le cadre de l’application, il est demandé que notre méthode soit capable de trouver l’équilibrium d’un tableau de 25000 éléments en moins de 0.5 secondes. Nous allons donc mettre en place un test unitaire en utilisant l’attribut « TimeOut » du test. Pour jouer la sécurité nous allons nous placer dans une situation un peu plus défavorable :

1. Le tableau aura 50000 éléments.
2. L’équilibrium sera en fin de tableau (ce qui nous obligera à faire le plus de calculs).

Le test

[TestMethod]
[Timeout(500)]
public void BigArray_TestMustBeFast()
{
    //Construire un tableau non symétrique
    int total = 0;
    int[] bigArray = new int[50002];
    for (int i = 0; i < 50000; i++)
    {
        bigArray[i] = 1;
        total += 1;
    }
    bigArray[50000] = 0;
    bigArray[50001] = total;            

    int actual = Problems.Equilibrium.Equilibrium.FindEquilibrium(bigArray);

    Assert.AreEqual(50000, actual, "Equilibrium non trouvé. {0} au lieu de la valeur attendue", actual);

}

Plein de confiance nous relançons le test … pour découvrir qu’il échoue en « time out » Il va falloir retravailler notre code.

Le code

Allons analyser notre code. Je pense que vous avez tous assez rapidement trouvé la source de notre problème. Notre algorithme naïf à une complexité en O(n2). En effet nous avons imbriqué 2 boucles :

1. La boucle principale qui parcoure tous les éléments.
2. Les 2 boucles internes qui calculent la somme gauche et la somme droite en parcourant également tout le tableau.

Si nous voulons gagner en performance, il faut trouver un algorithme plus efficace. Je vous laisse un peu de temps?

En fait la solution est relativement simple en prenant un peu de recul. au lieu de repartir de 0 à chaque fois, nous allons tout simplement mettre à jour les sommes gauche et droite. L’algorithme de base est le suivant :

1. Etape 1 : i=0, sommeGauche = 0, sommeDroite = Somme(Valeur(1) à Valeur(n) ) ou n est le dernier élément du tableau
2. Etape 2 : i=1, sommeGauche = sommeGauche + Valeur(0), sommeDroite = sommeDroite ? Valeur(1)
3. Et ainsi de suite jusqu’à avoir trouvé un équilibrium ou avoir atteint la fin du tableau

Avec cet algorithme, la complexité tombe à O(n). En effet le temps d’exécution augmente linéairement avec la taille du tableau. Le code optimisé est le suivant

public static int FindEquilibriumOptimized(int[] inputArray)
{
    if ((inputArray == null) || (inputArray.Length == 0))
    {
        return -1;
    }
    else
    {
        long leftSum = 0;
        long rightSum = 0;
        int equilibrium = 0;

        for (int i = 1; i < inputArray.Length; i++)
        {
            rightSum += inputArray[i];
        }

        if (leftSum == rightSum)
        {
            return equilibrium;
        }
        else
        {
            for (equilibrium = 1; equilibrium < inputArray.Length; equilibrium++)
            {
                leftSum += inputArray[equilibrium - 1];
                rightSum -= inputArray[equilibrium];

                if (leftSum == rightSum)
                {
                    return equilibrium;
                }
            }
        }
        return -1;
    }
}

On croise les doigts, on relance le test et … le test passe en largement moins de 2 secondes. En fait, si l’on compare les 2 algorithmes on obtient les temps suivants :

• Algorithme long : 11.8950 ms
• Algorithme court : 0.0291 ms

Conclusion

Et voila, c’était la dernière partie de cette mini série sur mes premiers pas dans l’utilisation des tests unitaires avec Visual Studio (et dans la rédaction de billets par la même occasion). J’espère que cela aura pu servir à quelqu’un. Je suis preneur pour d’éventuelle remarques sur le fond ou la forme.

Bonne programmation et vivez heureux et prospère.

Le problème

 
Récemment j’ai du écrire une série de tests d’intégration automatisés. Ces tests impliquaient la création de nombreux profiles. Le critère d’unicité des profiles était l’adresse email. Les tests accédaient à un référentiel et je devais donc trouver une solution pour créer de manière sûre des adresses uniques (pour ne pas avoir d’échecs du à des données existantes dans le référentiel).

La solution

J’ai d’abord pensé à utiliser des GUIDs, mais cette solution ne me convenait pas. En effet le format des GUID impliquait de devoir les retravailler afin d’obtenir une adresse valide. En cherchant il y avait une solution plus simple.

J’ai utilisé la méthode Path.GetRandomFileName() dans l’espace de nom « System.IO ». Comme la msdn documentation oublie de le dire, cette méthode génère des chaines au format 8.3 (par exemple la3taras.ovb ). Ainsi la création d’une adresse est devenu aussi simple que le code suivant :

profile.Email = string.Format("{0}@acme.com", Path.GetRandomFileName());

Joyeuse programmation et Longue vie et prospérité.

Démarche TDD – Une première tentative

Lors du dernier billet, nous en étions resté aux cas basiques. Voyons maintenant d’autres tests qui vont nous permettre d’arriver à une solution complète.

Cas du tableau à 2 éléments

Dans le cas d’un tableau à 2 éléments, il y aura un équilibrium si et seulement si il y a au moins un des 2 éléments qui est égal à 0. Le cas ou les 2 éléments sont à 0 est particulier car il repose sur notre convention de prendre l’équilibrium le plus petit en cas de plusieurs équilibriums. On a dons les cas suivants:

• i – 0 => 0
• 0 – j => 1
• i – j => -1
• 0 – 0 => 0

avec i != 0 et j != 0.

Test 04

Au lieu d’écrire 4 tests séparés, nous allons utiliser une fonctionnalité des tests MS Tests qui permet de fournir un jeu de données et de réponses en entrée du test. Le test sera donc exécuté autant de fois qu’il y a de jeux de données. Dans notre cas la source en entrée est un fichier XML. Les autres possibilités offertes sont un fichier CSV soit une base de donnée. Voici le fichier de tests (désolé pour l’affichage, je n’ai pas réussi à le rendre plus lisible sur le blog) : 

<?xml version="1.0" encoding="utf-8" ?><tests><test><name>0-0</name> <data>0,0</data> <expected>0</expected> </test><test><name>1-0</name> <data>1,0</data> <expected>0</expected> </test><test><name>0-1</name> <data>0,-1</data> <expected>1</expected> </test><test><name>1-1</name> <data>1,1</data> <expected>-1</expected> </test></tests>

Le Test

Le test en lui même est assez simple

[DeploymentItem("ProblemsTests\\Equilibrium\\TestsData\\2_Elelments_Arrays.xml"), DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\2_Elelments_Arrays.xml", "test", DataAccessMethod.Sequential), TestMethod]       
public void Simple_Array_With_2_Elements()
{
    string[] input = TestContext.DataRow[1].ToString().Split(new char[]{','});
    int[] inputArray = Array.ConvertAll<string, int>(input, delegate(string s) { return int.Parse(s); });
    int expected = Convert.ToInt32(TestContext.DataRow[2]);
    int actual;

    actual = Problems.Equilibrium.Equilibrium.FindEquilibrium(inputArray);

    Assert.AreEqual(expected, actual,"Test failed for case {0}", TestContext.DataRow[0]);
}

On remarque quelques nouveautés par rapport au tests précédents.

1. Le nom de la méthode est décoré avec « DeploymentItem » qui indique ou se trouve le fichier xml source et d’autres  paramètres. Ceci permet d’indiquer que nous avons un test « dirigé par les données » ou « data driven test ». Pour plus de détails concernant la façon de mettre cela en place je vous renvoie au blog suivant :
   
   |VS 2008] Jeux de données XML et CSV pour tests unitaires
2. Le tableau en entrée et créé à partir de la valeur du noeud « data » que nous convertissons en tableau d’entiers grâce à « Array.ConvertAll ».
3. Le résultat attendu est lu à partir du noeud « expected ».

En exécutant le test on a un échec car les cas 3 et 4 ne sont pas correct (ce qui est logique puisque notre implémentation actuelle ne retourne que la valeur 0 pour un tableau non nul. Corrigeons donc notre code?

Le code

Voici une première version du code qui passe tous les tests et qui est naïvement simple.

public static int FindEquilibrium(int[] inputArray)
{
    if ((inputArray == null) || (inputArray.Length == 0))
    {
        return -1;
    }
    else
    {
        if (inputArray.Length == 1)
        {
            return 0;
        }
        else
        {
            if (inputArray[1] == 0)
            {
                return 0;
            }
            else if (inputArray[0] == 0)
            {
                return 1;
            }
            else
            {
                return -1;
            }
        }
    }            
}

Ce code fonctionne mais l’imbrication de conditions donne un sentiment de code mal écrit. Tentons d’améliorer les choses. Tant que le tableau n’avait pas plus d’un élément il était possible de donner le résultat en un seul test. A partir de 2 éléments, on voit qu’il faut plusieurs tests. Il est donc temps, je pense, de réfléchir à un algorithme plus proche de la définition. Voici le résultat auquel j’arrive :

public static int FindEquilibrium(int[] inputArray)
{
    if (inputArray == null)
    {
        return -1;
    }
    else
    {
    
        for (int i = 0; i < inputArray.Length; i++)
        {
            var sommeGauche = 0;
            for (int j = 0; j < i; j++)
            {
                sommeGauche += inputArray[j];
            }

            var sommeDroite = 0;
            for (int k = i + 1; k < inputArray.Length; k++)
            {
                sommeDroite += inputArray[k];
            }

            if (sommeGauche == sommeDroite)
            {
                return i;
            }
        }
        return -1;
    }           
}

Nous avons implémenter le définition de l’équilibrium presque mot pour mot. Nous parcourons les éléments du tableau et additionnons les éléments à gauche de l’élément courant avec les éléments à droite de l’élément courant. On remarquera ici que je n’utilise pas une taille fixe pour le tableau mais bien la taille réelle? Ceci n’est pas une anticipation d’un test futur mais bien une volonté de ne pas utiliser de constante « magique » dans le code. Utiliser directement la valeur « 2 » aurait masqué le fait qu’il s’agit de la taille de mon tableau.

En première intention j’avais mis le bloc implémentant l’algorithme (c’est à dire les 2 boucles imbriquées) le bloc « else » correspondant au cas (taille du tableau > 1). En prenant ensuite un peu de recul j’ai remarqué que les cas tableau à 0 et 1 élément étaient également couverts par la boucle imbriquée. Je pouvais donc retirer les tests « inputArray.Length == 0″ et « inputArray.Length == 1″ ce qui simplifie encore le code.

Cas du tableau à 3 éléments

L’étape suivant consiste à traiter les tableaux à 3 éléments. Cette fois la partie ardue à consister à déterminer les cas de tests pertinents pour éviter d’avoir à faire toutes les combinaisons possibles. J’en suis arrivé à isoler 4 cas qui couvrent (sauf erreur de ma part) toutes les configurations pour un tableau (i,j,k) :

1. Somme droite nulle (j+k = 0) : résultat = 0
2. Somme droite non nulle (j+k != 0) et somme gauche nulle (i + j = 0) : résultat = 2
3. Somme droite non nulle (j+k != 0) et somme gauche non nulle (i+j != 0) et symétrie centrale (i = k) : résultat = 1
4. Somme droite non nulle (j+k != 0) et somme gauche non nulle (i+j != 0) et pas de symétrie centrale (i != k)  : résultat = ?1

On obtient le jeu de test suivant :

<?xml version="1.0" encoding="utf-8" ?><tests><test><name>Cas 1: somme droite nulle (j+k = 0)</name> <data>145887,14770,-14770</data> <expected>0</expected> </test><test><name>Cas 2: Symetrie centrale (i == k) avec somme droite non nulle (j+k != 0)</name> <data>-54,1,-54</data> <expected>1</expected> </test><test><name>Cas 3 somme gauche nulle (i+j = 0) et somme droite non nulle (j+k != 0)</name> <data>-15,15,1024</data> <expected>2</expected> </test><test><name>Cas 4: aucune symetrie (i != k), somme droite non nulle, somme gauche non nulle </name><data>1,2,3</data> <expected>-1</expected> </test></tests>

Le test

Le code du test est le même que celui du test précédent. Seul le fichier source va changer.

Le code

Ici on constate que tous les cas passent avec succès. Le code fonctionne donc très bien sur les tableaux à 3 éléments.

La suite …

A partir des différents tests mené, j’assume que les combinaisons avec des tableaux de tailles > 3 peuvent se ramener à un des cas de tableau à 3 éléments. Par exemple pour un tableau à 4 éléments (i, j, k, l) si i est l’équilibrium, il sera aussi l’équilibrium du tableau (i, j, k+l) ou (i, j+k, l). Et ainsi de suite. Par sécurité j’ai tout de même rajouté un test avec un fichier contenant quelques tests de tableaux supérieurs à 3. Aucune modification de code n’a été nécessaire. Je vous laisse essayer des cas avec le code fournis. Si vous trouvez une configuration qui n’est pas couverte n’hésitez pas à m’en faire part.

Je considère donc qu’il n’est pas nécessaire de faire plus de tests pour valider le bon fonctionnement du code. Par contre il nous reste quelques tests un peu plus subtils à écrire. Nous verrons cela dans le dernier article de la série.

La démarche et le sujet

Pour cet exercice je me suis forcé à appliquer au plus prêt ce que je pense avoir saisi de la démarche TDD. C’est à dire :

1. Ecrire d’abord un test qui échoue
2. Ecrire le code minimum pour faire passer le test. C’est à dire qu’à chaque étape il ne faut pas anticiper le code pour un test futur.
3. Après chaque modification faite pour passer un nouveau test, il faut prendre du recul et modifier le code afin de le rendre « propre » (ce que je traduis par faire que le code respecte les principes de développement comme le fait de supprimer les répétitions, de s’assurer que chaque classe et méthode à bien une seule responsabilité …).

Pour appliquer ces principe, j’ai choisi de prendre un essai de résolution d’ un petit problème informatique assez simple et connu : la recherche de l’équilibrium. Petit énoncé du sujet pour rappel :

Etant donné une suite d’entier dans un tableau, il faut trouver la position dans le tableau à partir de laquelle la somme des entiers de gauche est égale à la somme des entiers de droite (on ne compte pas la valeur de l’élément pivot). Prenons un exemple :

Soit le tableau A[0]=-7 A[1]=1 A[2]=5 A[3]=2 A[4]=-4 A[5]=3 A[6]=0  les équilibrium possibles sont:
3 => A[0]+A[1]+A[2]=A[4]+A[5]+A[6]
6 => A[0]+A[1]+A[2]+A[3]+A[4]+A[5]=0 et la somme de 0 éléments est aussi égale à 0 (il n’y a pas d’élément au delà de l’indice 6).

Les bases de l’exercice étant posée, passons au vif du sujet : la réalisation d’une méthode qui prend en argument un tableau d’entiers et qui

• renvoie l’équilibrium d’indice le plus bas s’il existe au moins un équilibrium : le fait de retourner l’indice de plus bas niveau est un choix purement arbitraire.

• la valeur -1 si aucun équilibrium n’est trouvé.

Maintenant que le contexte est posé, passons au codage.

Le codage

Nous allons donc créer des tests de plus en plus évolués. A chaque étape je vais présenter le code obtenu pour passer le test.

Cas du tableau « null »

Ce premier cas est totalement trivial. Si on passe un tableau vide à la fonction, elle doit renvoyer -1.
Ecrivons donc ce premier test à l’aide de MS Test (inclus dans la version beta de Visual Studio 2010).

Test 01

[TestMethod()]
        public void Simple_NullArray_NoEquilibrium()
        {
            int[] inputArray = null; 
            int expected = -1; 
            int actual;

            actual = Equilibrium.FindEquilibrium(inputArray);
            
            Assert.AreEqual(expected, actual);            
        }

Le code

Ecrivons maintenant le minimum de code pour faire passer ce test. Ici ma principale difficulté était de ne pas écrire trop de code en anticipant ce qui allait venir.

public class Equilibrium
{
    public static int FindEquilibrium(int[] inputArray)
    {
        return -1;
    }
}

Plus simple que ça, je ne vois pas.

Cas du tableau vide

Cette fois ci nous allons envoyer un tableau vide à la méthode. Comme il n’y a pas d’indice défini, la réponse doit à nouveau être -1. Ecrivons donc le test.

Test 02

[TestMethod()]
public void Simple_EmptyArray_NoEquilibrium()
{
    int[] inputArray = new int[] {};
    int expected = -1;
    int actual;

    actual = Equilibrium.FindEquilibrium(inputArray);

    Assert.AreEqual(expected, actual);
}

Le code

Comme nous avons écris du code robuste ce test passe au la main. Il n’y a pas besoin d’ajouter du code à notre code précédent.

Cas du tableau à 1 élément

Notre prochain cas va s’occuper de traiter un tableau contenant un seul élément. Dans ce cas, la fonction doit retourner 0. En effet à gauche et à droite de l’unique élément il n’y a rien => somme de 0 de chaque coté. On remarquera au passage que le valeur stockée dans le tableau n’a pas d’importance.

Test 03

[TestMethod]        
public void Simple_Array_1_Return_0()
{
    //La valeur réelle de l'élément n'a aucune importance dans ce cas
    int[] inputArray = new int[1] { 1 };
    int expected = 0;
    int actual;

    actual = Equilibrium.FindEquilibrium(inputArray);

    Assert.AreEqual(expected, actual); 
}

Remarque : je n’ai pas voulu mettre un nombre aléatoire dans le tableau car je pense que chaque exécution d’un test doit se comporter de la même manière. Un élément aléatoire risquerait d’introduire un comportement dans lequel le test échouerait de manière non prédictive, ce qui nuit à la confiance accordée aux tests. J’ai donc préféré ajouter un commentaire expliquant que le choix de la valeur 1 n’a pas d’importance dans notre cas.

Cette fois ci notre implémentation ne passe pas le test 03. Il faut donc modifier le code.

Le code

public class Equilibrium
{
    public static int FindEquilibrium(int[] inputArray)
    {
        if ((inputArray == null) || (inputArray.Length == 0))
        {
            return -1;
        }
        else
        {
            return 0;
        }            
    }
}

Nous avons regroupé les cas qui doivent renvoyer -1 et ajouter un else qui retourne 0. Même si nous savons que cette solution est imparfaite, elle convient cependant à tous nos tests et c’est ce que nous gardons à ce stade.

Et la suite …

Pour l’instant nous avons couvert les cas simple. Le prochain billet couvrira de nouveau cas. En attendant ce billet je te laisse, cher lecteur, réfléchir aux tests à rajouter. Tu pourras ainsi également comparer le résultat auquel tu seras arrivé avec mon résultat.

PS : Ceci est mon premier billet, merci de faire preuve d’un peu d’indulgence. Par contre les critiques constructives sur le fond ou la forme sont les bienvenues.

A bientôt

Live long and prosper