IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Qualimétrie Discussion :

Rien de plus que les tests d'intégration?


Sujet :

Qualimétrie

  1. #1
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2011
    Messages
    366
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2011
    Messages : 366
    Points : 1 361
    Points
    1 361
    Par défaut Rien de plus que les tests d'intégration?
    Bonjour,

    Je fais de l'informatique de gestion depuis 8 ans. Depuis que je développe en entreprise, j'ai constaté que l'on mettait en place beaucoup de tests unitaires (TU). Des outils comme Sonar permettent de suivre aussi un peu la qualité. Une fois le développement terminé, çà passe en général par une équipe de QA (quality assurance) qui teste que le développement n'a rien cassé.

    Mes questions sont les suivantes:
    • est ce que vous pensez que TU + Tests d'intégration + QA suffit en général?
    • est ce que vous incluez d'autres pratiques?
    • est ce que vous avez développé des systèmes "critiques" avec une meilleure méthodologie de tests?
    • et si oui, quels outils utilisez vous?


    Merci beaucoup
    les raisonnables ont duré, les passionné-e-s ont vécu

  2. #2
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Points : 7 275
    Points
    7 275
    Par défaut
    Bonjour,

    Le sujet des tests est très vaste. Pour moi, il ne faut pas nécessairement aller à la surenchère en déployant des tests unitaires, des tests d'intégration, des tests fonctionnels, des tests d'UI... L'important, c'est de disposer de bons tests. Par bons, j'entends :

    • utiles, c'est-à-dire qu'ils testent effectivement quelque chose. Par exemple, écrire un test unitaire sans faire d'assertion dedans, ça ne sert à rien. De même, s'ils ne testent que des parties pas ou peu utilisées, ça les rendra moins intéressants. Une bonne idée est, lorsque l'on doit corriger un bug, d'écrire les tests qui détectent le problème, puis de corriger le code afin que les tests réussissent. Ainsi, le bug est corrigé, et des tests ont été mis en place pour s'assurer qu'il n'y aura pas de régression dans le futur.
    • maintenables, car sans cela, les tests risquent d'être abandonnés ou obsolètes.
    • exécutables. L'idée d'un test est de détecter le plus rapidement possible les éventuels problèmes, de s'assurer également que les nouveaux développements n'impliquent pas de régressions dans le code existant. Le fait d'avoir des tests exécutables permet de les lancer plusieurs fois par jour (ou a minima une fois par jour si ceux-ci sont un peu longs). Avoir des tests manuels est une bonne chose (il est difficile voire parfois impossible de tester certaines parties de son application sans intervention humaine), mais hélas cela est couteux, beaucoup plus longs, moins réactif, et pas forcément exempt d'erreur.
    • performants. Comme je l'ai dit juste avant, l'intérêt d'un test est de détecter les erreurs le plus vite possible. Grâce à un serveur d'intégration continue, un développeur peut être averti d'une erreur dans son commit quelques minutes seulement après qu'il l'a réalisé. Cela permet donc au développeur de corriger l'erreur sans problème, car il n'aura pas à se remettre dans tout le contexte... Mais cela ne peut se faire que si ces tests s'exécutent rapidement. Si la compilation + tests d'une application met 1 heure à se faire, la réactivité s'en trouvera forcément impactée. Dans une telle situation, j'ai tendance à diviser les tests en 2 catégories : les tests rapides, qui sont exécutés aussi souvent que possibles, et les tests plus lents, exécutés au moins une fois par jour (durant le "nightly build" qui analyse également la qualité du code avec Sonar).


    Pour résumer : il faut favoriser la qualité des tests à leur quantité.
    Je te conseille aussi de privilégier l'approche TDD (Test Driven Development, ou Développement Piloté par les Tests), qui permet d'écrire du code tout en augmentant la base de tests disponibles dans l'application. En plus, cela améliore souvent le design du code écrit...
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  3. #3
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2011
    Messages
    366
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2011
    Messages : 366
    Points : 1 361
    Points
    1 361
    Par défaut
    Merci beaucoup pour ta réponse. En fait, je suis d'accord avec toi sur cette façon de tester. Tu mentionnes une usine logicielle complète, avec analyse statique de code, et on est d'accord là dessus. Tu dis que plus important que la quantité de tests, la qualité prime. Là encore, ok.

    Est ce qu'elle te parait, avec la pratique, suffisante?

    Moi pas. Oui, on développe en TDD dans les équipes un peu motivées, et déjà, hélas, c'est rare. Maintenant, un TU va tester une méthode "simple", et tu sais qu'il y a peu de risques d'erreur. C'est à l'assemblage, quand on va commencer les tests d'intégration, que les risques sont les plus grands.

    L'autre grosse source de risque, voire de mécontentement, c'est l'adéquation besoin / specs. En banque finance, malgré des tests unitaires, çà m'est arrivé de livrer de la merde, parce que personne n'a pris soin de vérifier que le design collait au besoin du client. Est ce que tu recommandes de pousser plus loin avec le BDD? Qui le définirait?

    En fait, j'ai l'impression que le test unitaire est la seule bonne pratique compatible avec les délais serrés qu'on a... Qu'en dis tu?
    les raisonnables ont duré, les passionné-e-s ont vécu

  4. #4
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 803
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 803
    Points : 32 056
    Points
    32 056
    Par défaut
    Le TU garantit qu'on livre un produit de qualité. Il ne garantit pas qu'on livre le produit dont avait révé le demandeur.

    En tant qu'ancien homologateur, je suis toujours stupéfait par des projets d'importance qui se permettent de ne pas avoir d'homologation dédiée. Il est rare d'avoir des spécifications claires, il est encore plus rare d'avoir des spécifications complètes.

    Nombre d'anomalies que j'ai relevé n'auraient pas été empechées par des tests unitaires(ça ne les empêche pas d'être indispensables, romaintaz explique mieux que moi pourquoi), ou tout test automatisé. Un oeil humain est indispensable, à mon sens, pour voir certains trucs.

    Je me souviens encore(ça remonte à 2005) d'une anomalie concernant la pagination, qui faisait des trucs bizarres, si et seulement si on avait 11 éléments et qu'on en supprimait un(on en avait 10 par page).

    Ce genre de bug ne se detecte pas par automatisme. Il ne s'anticipe pas. Et, généralement, un programmeur n'aura pas le cas sous les yeux quand il joue avec l'appli. Seul un testeur dédié, qui a pour seul objectif de faire chialer les développeurs, peut trouver certaines choses. Si la QA, comme tu la décris, se limite à vérifier la non régression, alors elle loupera aussi tout ça. D'ailleurs, la non-regression, dans un monde idéal, ça s'automatise. Pas les cas exotiques.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  5. #5
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2011
    Messages
    366
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2011
    Messages : 366
    Points : 1 361
    Points
    1 361
    Par défaut
    Merci pour ta réponse. Elle me plait d'autant plus que, d'expérience, les QA se contentent de tester que rien n'est cassé, plutôt que de vérifier les cas un peu complexes auxquels les développeurs n'ont pas pensé.

    J'avais regardé en fait comment on teste dans l'aéro ou dans le nucléaire. Avant de me dire que le but n'est pas le même, laissez moi vous dire que j'avais beaucoup aimé deux aspects:
    • Une classification des composants par risque et conséquences. En substance, si un composant défectueux n'empêche pas un avion de voler, on le teste à peine. Si en revanche, il est critique, il est testé, prouvé, revu par une autre équipe.
    • Une méthode d'analyse qui sort de ce qu'on connait. Par exemple, les FMEA permettent de classer ce qui a le plus chance de merder, pour mettre en place une solution adaptée au plus risqué ou au plus sensible.


    On n'a pas çà du tout en banque finance. Romaintaz parlait quand même de pertinence, mais c'est laissé au soin du développeur. Comme tout le monde n'a pas une motivation extrême pour la qualité, il y a un risque

    Bref, je me dis que la qualité n'est absolument pas garantie par une usine logicielle, comme le faisait remarquer el_slapper. Je me dis aussi qu'il existe plein d'autres méthodes de tests qu'on n'utilise absolument pas. Pourquoi? Par manque d'argent. Conséquence: les produits livrés marchent dans les cas standards, mais dès qu'on en sort, c'est la catastrophe.

    Quels sont pour vous les buts du test? Livrer un logiciel sans faille? Se rassurer sur son code? Avoir la possibilité de refactorer du code en garantissant de ne rien casser? Trouvez vous que la qualité de vos livrables est parfaite? Suffisante?
    les raisonnables ont duré, les passionné-e-s ont vécu

  6. #6
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Points : 7 275
    Points
    7 275
    Par défaut
    Pour information, je travaille aussi pour une banque Hélas, la qualité est très loin d'être bonne, voire même suffisante. Le problème de l'offshore - extrêmement présent dans les départements où je travaille - n'arrange rien, bien au contraire. Les indiens sont trop peu sensibilisés aux tests, bien que ça s'améliore. Mais c'est un autre débat.

    Revenons-en aux tests. Idéalement, il ne faut pas choisir entre TU et TI (intégration), il faudrait les 2 - et encore, je me limite à ces 2 types de tests. Effectivement, les TU permettent de s'assurer qu'un bout de code, pris isolément, fait ce qu'il doit faire. Cela ne veut pas dire qu'une fois intégré avec le reste, il se comporte toujours aussi bien, ou que l'application dans son ensemble répondent aux besoins. C'est plus le rôle du TI (ou tests fonctionnels, tests d'acceptance, peu importe le nom).
    Nous sommes justement en train de mettre en place du BDD (en plus des tests existants), basé sur Cucumber (cucumber-jvm). L'intérêt est multiple :

    • Permettre d'écrire des tests vraiment fonctionnels, avec un langage "humain" (en anglais, mais il est possible de les écrire en français ou n'importe quelle langue).
    • Permettre aux BA (la MOA) de participer à l'écriture des tests.
    • Ecrire des tests plus proches d'une vraie utilisation de l'application.
    • Faire partie intégrante des spécifications.


    L'idée derrière tout ça, c'est qu'au lieu de fournir un "simple" document expliquant telle ou telle fonctionnalité, on écrit la spec avec en plus une série de tests fonctionnels, au format BDD, c'est-à-dire :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Given <dans un contexte précis>
    When <si une action est réalisée>
    Then <alors je m'attends à tel résultat>
    Ces tests, écrits en collaboration entre la MOA et la MOE est en gros un contrat, disant que la fonctionnalité peut être considérée comme faite une fois que ces tests d'acceptance seront tous verts.

    A part ça, il faut se mettre dans l'idée que l'on ne peut pas fournir un code parfait. Prennons l'exemple d'un TU. Quand bien même je dispose d'une couverture de code de 100%, cela ne me permet pas de dire que le code n'aura jamais d'erreur. Il faut se concentrer d'abord sur les parties critiques de son application. Comme l'a dit rmaker, il faut prendre en considération le contexte de son application. Imaginons que j'écrive une fonction qui rétourne le résultat d'un jet de dé à 6 faces. Si cette fonction est un "gadget" dans mon application, quelques tests unitaires simples suffisent, pour s'assurer que les résultats me retourne des valeurs entre 1 et 6. Mais si je suis en train de développer un jeu de 421 pour la Française des Jeux, cette fonctionnalité va être critique. Tester simplement que la fonction retourne des valeurs entre 1 et 6 n'est pas suffisant. Il va falloir que je développe aussi des tests pour m'assurer que le 1 a autant de chance de sortir que le 2, etc. Du coup, je vais me lancer dans l'écriture de tests complexes, impliquant des maths et de la probabilité.
    Hélas, dans ce cas, aucun indicateur (par exemple via Sonar) ne va quantifier la qualité de mes tests. Dans les 2 cas (TU simples vs TU complexes), la couverture de code sera sans doute la même, mais les TU complexes me permettront d'avoir une plus grande confiance dans mon code.

    Pour résumer - j'écrit trop là, et je pars dans trop de directions - je dirais ceci : écrire des tests doit me permettre d'avoir une plus grande confiance dans ce que je livre, et m'assurer que l'application va fonctionner au mieux, et être le plus robuste dans son coeur de métier. Essayer de trop tester n'est pas forcément une bonne chose, car cela s'avérera généralement plutôt contre productif. Comme disait l'un de mes amis, "le mieux est l'ennemi du bien".
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

  7. #7
    Membre expérimenté
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2011
    Messages
    366
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2011
    Messages : 366
    Points : 1 361
    Points
    1 361
    Par défaut
    Citation Envoyé par romaintaz Voir le message
    Pour information, je travaille aussi pour une banque Hélas, la qualité est très loin d'être bonne, voire même suffisante.
    Précisément. On est bien d'accord là dessus. Le BDD dont tu parles ensuite me parait être la solution la plus facile, la plus réaliste et la moins chère.

    Citation Envoyé par romaintaz Voir le message
    Le problème de l'offshore - extrêmement présent dans les départements où je travaille - n'arrange rien, bien au contraire. Les indiens sont trop peu sensibilisés aux tests, bien que ça s'améliore. Mais c'est un autre débat.
    C'est dans le débat. Si tu demandes à tes équipes de faire du TDD ou du BDD et qu'à l'autre bout du monde, ça ne suit absolument pas.... tu as un projet à deux vitesses...

    Citation Envoyé par romaintaz Voir le message
    L'idée derrière tout ça, c'est qu'au lieu de fournir un "simple" document expliquant telle ou telle fonctionnalité, on écrit la spec avec en plus une série de tests fonctionnels, au format BDD
    Cà semble en effet la solution miracle. Est ce que tes amis MOA ont adhéré sur le principe? Est ce que vous arrivez à le faire vivre?

    Citation Envoyé par romaintaz Voir le message
    A part ça, il faut se mettre dans l'idée que l'on ne peut pas fournir un code parfait.
    Oui, c'est peut être çà le mot de la fin...

    Merci pour le temps et les réponses.

    En conclusion: BDD, TDD, faire au mieux.
    les raisonnables ont duré, les passionné-e-s ont vécu

  8. #8
    Rédacteur
    Avatar de romaintaz
    Homme Profil pro
    Java craftsman
    Inscrit en
    Juillet 2005
    Messages
    3 790
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Java craftsman
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2005
    Messages : 3 790
    Points : 7 275
    Points
    7 275
    Par défaut
    Pour répondre à tes interrogations sur le BDD : nous ne sommes pas très avancés, on est plus sur un "prototypage", pour voir justement si la MOA y voit un réel intérêt. Je pense qu'ils sont très ouverts là-dessus, qu'ils sont demandeurs de ce genre de choses.

    Mais il y a quelques obstacles :

    Tout d'abord, les problèmes de communication. De bons tests fonctionnels doivent être écrits conjointement entre les MOA et les MOE. Le souci chez nous, c'est que la majorité des premiers sont en France, la majorité des seconds en Inde. Je ne dis pas que ce n'est pas impossible, mais ça va demander peut-être de modifier notre approche sur la façon de travailler.

    Ensuite, ce n'est pas une solution Miracle. Ecrire des tests en BDD n'est pas de tout repos. Le principe de Cucumber est le suivant. Tout d'abord, j'écris un test dans un fichier texte (une feature, composée de Scenario), sous la forme suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Feature: Hello World
    
        Scenario: Say hello
            Given I have a hello app with "Howdy"
            When I ask it to say hi
            Then it should answer with "Howdy World"
    On y retrouve les 3 éléments Given, When et Then. Mais là où ça se complique, c'est qu'il faut ensuite "traduire" ces phrases en code Java. Techniquement, ça se fait facilement dans une classe Java :

    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    public class HelloStepdefs {
        private Hello hello;
        private String hi;
     
        @Given("^I have a hello app with \"([^\"]*)\"$")
        public void I_have_a_hello_app_with(String greeting) {
            hello = new Hello(greeting);
        }
     
        @When("^I ask it to say hi$")
        public void I_ask_it_to_say_hi() {
            hi = hello.sayHi();
        }
     
        @Then("^it should answer with \"([^\"]*)\"$")
        public void it_should_answer_with(String expectedHi) {
            assertEquals(expectedHi, hi);
        }
    }

    (exemple tiré du projet cucumber-jvm)

    Comme vous vous en doutez, la difficulté va être de coder ces éléments. On demande généralement à des tests BDD de réaliser des opérations plus haut niveau que ce qui est fait en TU. Du coup, il est parfois difficile de coder certaines actions, surtout si ces actions se font via une interface graphique (ce qui implique de rajouter une couche dans sa stack technique, avec Selenium / FluentLenium par exemple).
    Relativisons toutefois en se disant que l'écriture d'un test, de quelque nature qu'il soit, n'est pas forcément simple

    Un dernier point pour la route : l'outillage n'est hélas pas au top dans le domaine du BDD, mais ça s'améliorera sans aucun doute. Une grosse préférence pour IntelliJ sur ce point par rapport à Eclipse.
    Nous sommes tous semblables, alors acceptons nos différences !
    --------------------------------------------------------------
    Liens : Blog | Page DVP | Twitter
    Articles : Hudson | Sonar | Outils de builds Java Maven 3 | Play! 1 | TeamCity| CitConf 2009
    Critiques : Apache Maven

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 0
    Dernier message: 05/07/2015, 20h20
  2. [Cobertura] [Maven] inclure les tests d'intégration dans les rapports de qualité
    Par Tcharl dans le forum Qualimétrie
    Réponses: 1
    Dernier message: 02/05/2011, 22h33
  3. Que nous offre R de plus que les autres ?
    Par zangaloni dans le forum R
    Réponses: 1
    Dernier message: 28/02/2011, 22h45
  4. [Cobertura] [Maven] Instrumenter un WAR et analyser les tests d'intégration
    Par goldest dans le forum Qualimétrie
    Réponses: 2
    Dernier message: 27/04/2009, 19h42
  5. Qu'est-ce-que perl à de plus que les autres ?
    Par Celelibi dans le forum Langage
    Réponses: 7
    Dernier message: 24/08/2005, 02h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo