Tests

Méthode

De la complémentarité des démarches de test

Dans tout projet, les tests occupent une place très particulière. Leur vocation première est de s'assurer que le logiciel répond au besoin. Ils assurent ainsi le lien entre le monde des utilisateurs et le monde du développement. Les tests se retrouvent de manière très formelle - quasi juridique - dans le process de validation (le "PV de recette"). Ce rôle de point d'orgue du projet (sa conclusion) occulte très souvent la place réelle des tests, on oublie qu'ils ont participé très en amont à l'élaboration du livrable : derrière un PV de recette dûment signé, combien de bugs ont dû être préalablement corrigés, combien de chapitres a-t-il fallu revoir dans les spécifications ? Ces ajustements n'ont pas été produits ex nihilo, ils sont le résultat de la constatation d'une anomalie, d'un test en fait. S'ils ne sont pas formalisés, on les retrouve indirectement dans les écrits du projet : soit sous forme de complément de spécifications, soit aussi sous forme de correction de bug.

Lorsque le test n'est plus formalisé " sous le manteau " mais fait l'objet d'une démarche systématisée, on parle de démarche pilotée par les tests.

Trop souvent cette démarche est opposée à l'approche classique, et ce de façon manichéenne. Nous allons voir au contraire que les deux démarches sont complémentaires et que les outils correspondants peuvent être facilement intégrés.

Lire la suite
Archi & techno

Simplifier le développement des tests avec Unitils

Tout le monde s'accorde sur l'utilité des tests de non régression automatisés, d'ailleurs les outils disponibles dans la sphère Java sont légion : jUnit, dbunit, jmock ...
Mais de là à les voir mis en oeuvre systématiquement sur les projets il y a un pas ; l'un des reproches revenant le plus est : "les tests sont trop coûteux à écrire".

Unitils est une bonne réponse à ce problème.

Lire la suite
Archi & techno

Les tests de recette automatisés avec Fitnesse

Combien de développeurs se sont entendus dire : « Hum. hum, vous êtes sûr d'avoir bien compris la spécification détaillée ? » . Ou encore : « Avant, elle marchait bien cette fonction : pourquoi ça marche plus maintenant ?! ». Voire : « Mais on ne l'avait pas déjà fait corriger ce bug là ? Je comprends pas : plus vous codez. et moins l'appli fonctionne ?!? ».

Laissez faire le temps et vous pouvez être à peu près certain que spécifier, vérifier et assurer la non régression d'une application de gestion deviendra un douloureux défi. Il existe une solution encore méconnue des développeurs et des maîtres d'ouvrage : les tests de recette automatisés. Ils permettent de relever ce défi sans sarcasme, ni douleur.

A travers deux articles différents, l'un publié sur le portail DotNetGuru.org et l'autre publié dans le numéro de juillet de Programmez !, nous présentons Fitnesse, un outil de tests de recette automatisés qui permet de rédiger une spécification exécutable :

  • non ambigue entre maîtres d'ouvrage et développeurs ;
  • de manière produtive à l'aide d'un site Wiki ;
  • et vérifiée automatiquement sur le logiciel développé.

Pour la suite, ça se passe :

Messaoud

Lire la suite
Méthode

Tester pour contruire le bon logiciel: la relève…

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J'en entends déjà pester "encore un truc de geek"...Le pilotage par les tests se résume à ces deux points clés:

  • remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l'ambiguïté du langage courant par des spécifications exécutables c'est à dire vérifiables concrètement et fournissant une réponse sans appel: "vert" ou "rouge".

  • Piloter non pas sur un "reste à faire" - concept obscur car que met on dans le "reste à faire"? - mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d'avoir un outil permettant aux "fonctionnels" d'écrire simplement - c'est à dire dans leur vocabulaire - les spécifications exécutables et permettant aux "managers" de piloter les développements.

Lire la suite
Archi & techno

De l’insuffisance de la couverture de tests

Les besoins en terme de qualité de code amènent de plus en plus de projets à s'intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits "de couverture de tests" sont utilisés en complément.
Loin de moi l'idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

  • fournir une valeur quantitative représentant la part de logiciel testé
  • fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J'y vois là le double avantage :
  • de mieux maitriser le risque. Le code non testé est connu.
  • de permettre d'améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu'un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D'aucuns diront que si on fait du TDD ("Test Driven Development"), le code non testé est inutile et n'aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd'hui...
Reste que cet indicateur de "couverture de test" se contente de "voir" le code exécuté. That's all et ca n'est peut-être pas suffisant.

Lire la suite