Articles Marqués ‘Qualité’

Par Grégory Levilain • 8 fév, 2010 • Catégorie: Agilité, Java, Productivité, Qualité, Test

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Il va de soit que les tests représentent un gage de qualité pour un projet. Leur adoption dépend à mon avis de deux aspects :

  • une bonne méthodologie ;
  • une infrastructure adaptée.

Si les méthodes agiles et le TDD représentent un facteur de motivation, il serait dommage de ne pas les mettre en œuvre. Si ce n’est pas le cas, ou que le projet ne s’y prête pas, l’important à mon sens est de créer un besoin. L’un des aspects essentiels du développement assisté par les tests est de fournir un maximum de confort et de possibilités aux développeurs, afin de faire du test unitaire un outil de développement apprécié et indispensable.

Quelque soit la solution choisie, sa pérennité dépend fortement de la mise en place de l’infrastructure et de l’outillage nécessaires. L’intégration continue, notamment, est capitale.

Enfin, une solution de tests fonctionnels complètera efficacement l’une ou l’autre des méthodes citées.



Par Grégory Levilain • 8 fév, 2010 • Catégorie: Agilité, Java, Productivité, Qualité, Test

1) Introduction
2) Développement “piloté par les tests” vs “assisté par les tests”
3) Tests unitaires “en isolation” ou “contextuels” ?
4) Gestion des données de tests et choix des outils
5) Conclusion

Gestion des données

Pour résumer, l’objectif est ici de placer la BDD dans un état prédéfini avant le test, de façon automatique, afin d’assurer sa reproductibilité. De plus, cette initialisation doit se faire :

  • de façon suffisamment rapide pour que la durée d’exécution des tests ne devienne pas une contrainte ;
  • de façon suffisamment souple pour injecter facilement toutes sortes de données. En outre, une méthode d’insertion dynamique permettra par exemple de créer des listes volumineuses pour tester un composant de pagination ou de tri.

Les tests contextuels nécessitent des jeux de données plus conséquents que les tests en isolation. Malgré tout, il est important que ceux-ci restent suffisamment légers pour conserver des performances acceptables.

Pour organiser ces jeux de données de façon optimale, nous distinguerons :

  • La structure de la BDD ;
  • Les données de référence, qui se trouvent dans des tables qui ne sont jamais modifiées lors de l’utilisation habituelle de l’application. Exemples: Table “CIVILITE” (Mr, Mme, Mlle), …








  • Par Grégory Levilain • 1 fév, 2010 • Catégorie: Agilité, Java, Productivité, Qualité, Test

    1) Introduction
    2) Développement “piloté par les tests” vs “assisté par les tests”
    3) Tests unitaires “en isolation” ou “contextuels” ?
    4) Gestion des données de tests et choix des outils
    5) Conclusion

    En pratique, que l’on choisisse le TDD ou une autre méthodologie, la complexité majeure de mise en œuvre réside dans la gestion des données de tests. La problématique consiste à placer la base de données dans un état prédéfini, avant l’exécution de chaque test, de façon automatique.

    Par ailleurs, la politique de gestion des données est déterminante pour choisir les outils appropriés.

    En TDD, les tests unitaires sont réalisés en pure isolation. C’est-à-dire que chaque fonction est testée en l’isolant de son contexte d’exécution afin d’éviter toute interférence externe qui risquerait de compromettre le résultat du test. C’est pour cela que les implémentations “mock” comme EasyMock ou Mockito (Mockito in six easy examples) sont très utilisées en TDD. L’isolation réduit aussi considérablement le volume de données de tests à gérer. Des outils comme DBUnit et SpringUnit, qui permettent de spécifier en XML les données attendues …






    Par Grégory Levilain • 25 jan, 2010 • Catégorie: Agilité, Java, Productivité, Qualité, Test

    1) Introduction
    2) Développement “piloté par les tests” vs “assisté par les tests”
    3) Tests unitaires “en isolation” ou “contextuels” ?
    4) Gestion des données de tests et choix des outils
    5) Conclusion

    Développement piloté par les tests

    L’engouement pour les techniques “Agiles”, et plus particulièrement l’”Extreme Programming” a conduit de nombreux informaticiens à se demander si les méthodes TDD — “Test Driven Design” ou “Test Driven Development” — ne seraient pas la solution pour enfin promouvoir les tests dans leurs projets. En effet, en substituant l’approche traditionnelle “Coder-Tester-Déboguer” par l’approche “Tester-Développer-Remanier”, le TDD place les tests au cœur du processus de développement.

    Mais ce qui rend délicat son adoption, c’est qu’il s’agit avant tout d’une méthode de conception “Agile”, à laquelle l’équipe projet doit être formée. Cette méthode a pour objectif premier de réduire les cycles de livraison. En codant le strict minimum requis entre chaque cycle, on évite les incompréhensions et l’on peut s’adapter aux changements.

    Le cycle de développement préconisé est le suivant :

  • écrire un test ;
  • vérifier que ce test échoue ;
  • écrire juste le code suffisant pour passer le test ;
  • vérifier que le test passe ;
  • remanier le code pour l’améliorer tout en gardant les mêmes fonctionnalités.
  • Aujourd’hui, le …







    Par Grégory Levilain • 18 jan, 2010 • Catégorie: Agilité, Java, Productivité, Qualité, Test

    Comment promouvoir les tests dans le processus de développement d’une application de gestion Java EE ? Quels outils mettre en place ? Comment sensibiliser les développeurs ? Le développement piloté par les tests (TDD) est-il incontournable pour obtenir une solution pérenne ?

    Le choix d’une solution de test est délicat. La multitude d’outils disponibles sur le marché est impressionnante. L’une des forces du TDD est qu’il repose sur une méthodologie clairement définie et des objectifs précis. Et c’est cette méthodologie qui détermine les outils nécessaires.

    Dans certains cas, le TDD peut s’avérer inapproprié. L’essentiel pour obtenir une solution pérenne est alors de commencer par déterminer la méthodologie et les objectifs que l’on souhaite atteindre.

    A travers cette série de billets, je vous présenterai ma vision des choses en comparant le concept de “développement assisté par les tests” à celui du “développement piloté par les tests”.

    1) Introduction
    2) Développement “piloté par les tests” vs “assisté par les tests”
    3) Tests unitaires “en isolation” ou “contextuels” ?
    4) Gestion des données de tests et choix des outils
    5) Conclusion



    Par Nicolas Rougé • 21 oct, 2009 • Catégorie: Java, Qualité, Test

    Les tests unitaires classiques sont utilisés pour tester une partie du code d’une application, dans un environnement d’exécution bien maîtrisé. Même si les tests de ce genre sont nécessaires, et que leurs bénéfices ne sont plus à démontrer, il est également important de pouvoir réaliser de véritables tests fonctionnels d’une application web, en condition réelle, c’est à dire déployée sur un serveur d’application et en la testant depuis un navigateur. Selenium est un des outils les plus utilisés pour réaliser ce genre de tests. Après une présentation rapide de cet outil, cet article a pour but de vous exposer mon retour d’expérience sur son utilisation au quotidien.

    Selenium est en fait un ensemble d’outils, dont les plus importants sont :

    • Selenium IDE : plugin pour Firefox qui permet d’enregistrer et de rejouer des commandes utilisateur sur une application web - ouverture d’une URL, click sur un bouton, entrée d’une valeur dans un champ, etc. Ces commandes peuvent être exportées sous la forme de tests unitaires dans différents langages (HTML, Java, C#, etc.)
    • Selenium Core : bibliothèque JavaScript, compatible avec un grand nombre de navigateurs, utilisée pour lancer les commandes utilisateur sur l’application web. Cette bibliothèque peut être utilisée directement pour lancer …




    Par Nicolas Rougé • 21 oct, 2009 • Catégorie: Build, Java, Java EE, Qualité, news

    Architecte et expert technique Java/JavaEE, je participe depuis plusieurs années à la mise en place et au développement de ces technologies sur un grand nombre de projets informatiques.

    Confronté au quotidien à la réalisation d’applications, mon expérience du terrain m’a amené à mettre en place un certains nombre de pratiques ayant fait leurs preuves : tests unitaires, contrôle de la qualité, intégration continue, etc.

    Mes thèmes de prédilection sont le monde de l’Open Source, la qualité logicielle, l’intégration continue et tout ce qui concerne l’automatisation des processus de développement, l’outillage du développeur, ainsi que les problématiques de conception et d’architecture des projets informatique. Ce blog est pour moi l’occasion de partager avec vous mon expérience et mon point de vue sur ces domaines.

    En vous souhaitant bonne lecture…



    Par Grégory Levilain • 27 mai, 2009 • Catégorie: Java, Java EE, Qualité

    L’utilisation d’un outil d’analyse de code tel que Checkstyle, PMD ou FindBugs permet d’assurer un certain niveau de qualité sur un projet : l’outil garantit un code homogène et permet aux développeurs débutants d’acquérir progressivement une partie des bonnes pratiques de la programmation en Java. Mais le caractère optionnel d’un tel outil met en péril son adoption sur certains projets.

    En effet, comme ce genre d’outils n’est nullement indispensable à la progression des développements, il est facile d’oublier de les installer. Du coup leur utilisation tient souvent de la bonne résolution de début de projet et finit par être délaissée au fur et à mesure que celui-ci prend de l’ampleur. Alors que les développements s’intensifient, de nouveaux développeurs arrivent, l’équipe se renouvelle, et Checkstyle n’est bientôt plus qu’un lointain souvenir. C’est en fait le lot de la plupart des outils liés à l’amélioration de la qualité et cela contribue à alourdir la dette technique des projets concernés (plus de détails sur la notion de dette technique ici).

    C’est pourquoi, à mon sens, la mise en place de tout process qualité dépend en grande partie de la capacité …




    Par Grégory Levilain • 27 avr, 2009 • Catégorie: news

    Après 6 ans passés à évoluer dans le monde Java et Java EE, je suis depuis 3 ans responsable de l’industrialisation et des environnements de développement de ProxiAD Nord. Ce poste est né d’un besoin récurrent en SSII : assurer la maîtrise de ses développements, en termes de qualité et de productivité.

    Vaste programme… et surtout un beau challenge parce qu’une application de qualité, c’est un peu comme une fricadelle : “tout le monde sait ce qu’y a d’dans, mais…”
    Bref, le challenge est sur le long terme évidemment. Un process qualité peut facilement être perçu comme une contrainte si on tente de l’imposer de but en blanc. Et c’est généralement justifié car les actions visant à améliorer la qualité peuvent s’avérer pénibles et même paraître contre-productives.

    Ma stratégie repose donc sur une approche plus globale dans laquelle le process qualité s’intègre à un ensemble d’outils et de services destinés d’une part à accroître effectivement la productivité sur le projet, d’autre part à fournir plus de confort aux membres de l’équipe. Dans ce contexte, les “actions qualité” retrouvent leur sens et leur plus-value. Cette méthode a l’énorme avantage de générer une demande plutôt qu’une contrainte.

    Le thème de la qualité logicielle dans un …