Tests

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…

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.

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…

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…

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.

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…

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…