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

Version imprimable

30/01/2013, 11h35
rmaker

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
31/01/2013, 09h27
romaintaz
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...
31/01/2013, 11h08
rmaker

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?
31/01/2013, 11h32
el_slapper

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.
31/01/2013, 11h55
rmaker
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?
01/02/2013, 09h46
romaintaz
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:

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".
01/02/2013, 11h25
rmaker

Citation:

Envoyé par romaintaz

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

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

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

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.

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:

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:

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.