« Et après avoir enregistré la livraison, on voit que le stock du produit… n’est pas mis à jour… »

Une application pas assez stabilisée, des scénarios déroulés de manière trop hasardeuse, un démonstrateur peu familier de l’application… l’ »effet démo » devrait alors être rapidement invoqué pour justifier les comportements inattendus et autres « stacktraces » présentés à l’écran devant un auditoire au mieux interloqué, au pire moqueur.

Pourtant, cet effet et les moments de solitude qui en découlent peuvent être maîtrisés avec peu de préparation. Au travers d’un cas réel, nous vous proposons dans cet article de parcourir les principales astuces vous permettant de sécuriser une démonstration et de combattre l’effet démo qui, un peu à la manière du « Plouf« , s’instille sournoisement dans les habitudes d’une équipe. Le cas pris pour exemple de cet article est un projet mené sur un mode « Scrum ». Cependant, le principe de la démo reste valable hors de ce contexte.

Vous trouverez en pièce jointe une checklist synthétisant les vérifications à faire afin de mettre toutes les chances de votre côté.

(Lire la suite…)

Mutation Testing

Il n’est plus à prouver l’utilité des tests unitaires. Ils sont essentiels dans la conception d’une application de qualité. Mais, savons-nous quantifier leur pertinence, leur qualité ?

Un indicateur de couverture du code par les tests à 100%, ne signifie pas du code 100% testé. Cet indicateur ne détermine que  grossièrement le pourcentage de code exécuté lors du passage des tests unitaires, pas plus.

Voici une technique qui vous permettra d’accorder plus de confiance à vos tests.

Le processus de cette technique se déroule en deux grandes étapes : la génération de mutants, puis le carnage de ceux-ci. WTF ?

(Lire la suite…)

L’approche « Behavior Driven Development », ou l’art d’écrire des tests qui décrivent le comportement attendu du système et que tout le monde comprend.

Dans cet article (en anglais), je présente l’architecture mise en place pour suivre cette démarche, dans un projet de développement d’un client lourd sous .NET/WPF, et comment l’utilisation du design-pattern MVVM nous a aidé à atteindre notre objectif.

La suite ici.

(Lire la suite…)

Travaillant avec les technos Web, j’ai souvent été confronté à Javascript.
Java-iste dans l’âme, j’ai été un peu rebuté par ce langage interprété (non compilé), faiblement typé, basée sur la notion de prototype (donc sans classe !)… bref, trop souple pour être vraiment sérieux !

Si on ajoute à cela qu’il existe un moteur par version de navigateur (actuellement on a Chakra chez IE9, V8 pour Chrome, TraceMonkey chez Firefox3.5, SquirrelFish pour Safari ou encore Carakan pour Opera10…) ce sont les maux  de tête assurés !

La solution: le TDD !
Cette méthode de développement est une bonne façon d’avoir un retour rapide sur son code et ainsi, de compenser le côté « non-compilé » de Javascript.
De plus, les tests unitaires sont particulièrement importants lorsque le typage est dynamique (comme c’est le cas en Javascript, mais aussi en Ruby, Groovy, Python, etc.). Dans ces environnements, c’est le harnais de test produit par le TDD qui permettra au développeur d’avoir la confiance suffisante pour faire du refactoring.

Il existe de nombreux frameworks de tests unitaires Javascript. On retiendra en particulier QUnit (l’outil de tests officiel de JQuery), Jasmine (orienté BDD et successeur de JSunit, le pionnier, sorti en 2001) ou encore le YUI Test de Yahoo.
Dans cet article, je vous présenterai JsTestDriver.
(Lire la suite…)

Tester l’IHM n’a jamais été chose aisée et globalement deux approches s’opposent :
- Tester avec du code. Le principal inconvénient est que cela repose principalement sur le nommage ou l’agencement des composants et – suivant le framework utilisé – peut être assez sensible au refactoring et notamment au modification d’imbrication des composants.
- Tester en mode recorder. Le principal inconvénient reste que ces tests ne peuvent être réalisés que très tardivement (et souvent pas par les équipes de développements) et sont sensibles aux modifications d’IHM (repositionnement d’un bouton etc…). Tout refactoring de ce type de tests est impossible et ces outils sont souvent croisés dans des contextes de pure non regression – ie. des contextes où le développement IHM est stable et où l’on souhaite facilement savoir si quelque chose a été cassée ou non.

Il existe quelques solutions de tests d’IHM pour Swing (Swing Unit, SpecUI4j…) mais j’ai envie de m’arrêter sur Fest Swing.
(Lire la suite…)

Si vous êtes un habitué de notre blog, vous saurez à quel point les démarches de développement piloté par le test (TDD) nous sont chères. Allié à un bon outil de test fonctionnel le TDD s’avère être un levier de productivité très important.

L’objectif de cet article est de vous présenter les différents types d’outils de tests fonctionnels puis de donner quelques perspectives sur les outils de tests du futur.
(Lire la suite…)

Dans un précédent article, Meriem Berkane introduisait le build distribué et notamment la distribution des tests sur des agents. TestNG propose cette fonctionnalité de base, JUnit par contre ne le fait pas. Mais Gridgain vient combler ce manque depuis sa version 1.6. Dans cet article, je vais donc mettre en oeuvre Gridgain dans un build Maven afin de pouvoir, par la suite, l’utiliser sur le serveur d’intégration continue.
(Lire la suite…)

Dans un projet d’entreprise, il est important de vérifier continuellement la non-régression du produit réalisé. Au même titre que les tests unitaires, les tests d’acceptance font partie intégrante du harnais de tests à mettre en place sur un projet. FitNesse est une des solutions à ce besoin.

FitNesse / Slim

FitNesse dormait jusqu’à Juillet 2008. Mais il suffit de voir le rythme des releases depuis cette date, pour se rendre compte qu’il s’est réveillé ! Avec une nouvelle version presque tous les mois entre Juillet 2008 et Juillet 2009, et l’arrivée de Slim, on obtient un produit qui a sensiblement changé.

Mais avec une évolution aussi soudaine, on ne peut malheureusement pas éviter les effets de bords. Notamment dans le monde des outils qui tournaient autour de la sphère FitNesse. Par exemple, je recherchais un plugin Maven pour FitNesse. Mais la plupart des liens que me renvoie mon moteur de recherche préféré, pointe sur des outils incompatibles avec les nouvelles versions de FitNesse.

Il faut creuser un peu avant de trouver les perles rares…

(Lire la suite…)

A la fin du précédent article, nous en étions restés à une application GWT testée unitairement :

• tous les comportements des contrôleurs sont testés
• les points difficiles des vues sont testés

Ces tests sont exécutés avec JUnit ou Maven, comme n’importe quel autre test. Nous sommes donc capables de lancer l’application GWT dans une JVM standard. Rien ne s’affiche, mais toutes les classes sont instanciées, et les comportements sont implémentés. Par contre la partie serveur (qui reçoit les appels GWT-RPC) est mockée.

La faiblesse de ces tests est qu’ils sont unitaires : on teste le comportement d’un écran. Or les problèmes commencent lors que l’on enchaine les écrans…
(Lire la suite…)

Dans le précédent article, nous avons démontré qu’il n’était pas si facile de faire des tests avec GWT car :

• La classe de test de base, GWTTestCase est trop restrictive (impossible d’utiliser des outils de tests), et est source de lenteurs
• Le mock de composants GWT requiert l’utilisation d’interfaces intermédiaires plutôt que des classes de composants, ce qui induit un gros travail de refactoring sur les projets existants

Nous avons donc mis en place une solution alternative…
(Lire la suite…)