Derrière cette formulation humoristique se cache un des fondements de l’industrialisation des développements : le fait de pouvoir tester de manière automatisée tout ou partie d’un système informatique.

Aussi bien dans les architectures complexes que dans les applications les plus simples, il est pertinent de pouvoir tester un composant logiciel unitairement (indépendamment des autres composants duquel il dépend) : les dépendances sont donc « mockées » ou simulées en français.

Il est aussi nécessaire de pouvoir créer un contexte favorable au scénario de test en injectant un jeu de données particulier via un automate de tests ou un injecteur.

Le développement d’applications Kinect n’échappe pas à cette nécessité. Voici comment simuler une Kinect avec la librairie MocKinect.
(Lire la suite…)

Objectif

Une des valeurs portées par le mouvement DevOps réside dans l’ouverture et l’échange des outils, bonnes pratiques, us et coutumes entre Devs et Ops. Essayons donc dans ce billet de tirer profit des bonnes habitudes du TDD et voir dans quelle mesure il y aurait matière à les piquer / adapter dans le monde du run et des infrastructures. Une idée serait de considérer l’infrastructure comme un système testable et donc mettre en place une stratégie systématique de TDI pour Test-Driven Infrastructure. Un changement, un test.

(Lire la suite…)

Vous êtes déjà un expert TDD, votre application a une couverture de tests de plus 80%. Mais vous avez le sentiment que tout n’est pas testé, qu’il reste d’obscurs cas que vous n’arrivez pas exprimer.

Pourquoi ne pas demander à un programme de vous aider à tester ?

Vous pouvez déjà passer par le mutation testing. Cette méthode donne une première approche, mais il en existe une autre : les tests par propriétés.

Cette méthode se résume à exprimer des propriétés et de laisser un programme la vérification de celles-ci.

C’est une façon de tester qui provient des langages fonctionnels et donc qui peut paraître étrange si on vient du monde objet « classique ».

Donc regardons plus en détail son fonctionnement et à quoi elle pourrait servir.
(Lire la suite…)

En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:

- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j’ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?

La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO…

(Lire la suite…)

A moins de s’être limité à dessiner des ronds et des carrés avec Silverlight, vous avez sans doute déjà tenté d’utiliser un des templates de projets du Silverlight Toolkit permettant de faire des tests unitaires pour vos applications RIA! Plein de bonne volonté, vous vous êtes heurtés aux multiples inconvénients de cette solution :

• Framework de tests spécifique à Silverlight
• Obligation de lancer une application « conteneur » pour lancer vos tests
• Usabilité plus que discutable de cette même application
• Impossibilité d’utiliser une métrique comme la couverture de code
• et j’en passe…

N’abandonnez pas encore ! Je vous proposer ici une solution pour venir à bout de ces limitations… plus d’ excuses, vous pourrez tout tester …

la suite par ici en anglais…

Il y a peu, je participais à une réunion de travail impliquant une trentaine de personnes et j’ai fait une observation qui m’a intrigué. Avez-vous remarqué ce qui se produit lorsqu’un téléphone portable sonne au cours d’une réunion ?

• La personne propriétaire du portable l’éteint rapidement
• Tous ceux qui ne l’avaient pas encore fait vérifient leur portable et activent discrètement le mode silence.

Voilà un exemple de mesure préventive particulièrement efficace! Dans les entreprises où l’on respecte un certain standard de réunion, l’exception que constitue la sonnerie d’un portable ne se produit qu’une seule fois, pas deux. La première “infraction” protège le groupe de toute nouvelle occurrence. Elle agit en quelque sorte comme un “vaccin” sur le fonctionnement du groupe en réunion.

Quelles conditions faut-il réunir afin de créer d’autre vaccins de ce type au sein d’une équipe ? (Lire la suite…)

Si vous avez déjà créé une application Ruby on Rails, vous avez déjà dû voir un étrange répertoire : tests.

N’ayez pas peur, tout a été fait pour faciliter la mise en place de tests de bout en bout avec Rails.

Je vais donc vous donner les méthodes que j’apprécie et que je considère efficaces pour l’écriture de tests en Rails. Que vous soyez novices ou expert, j’espère pouvoir vous en apprendre un peu.

Tous les exemples donnés seront pour Rails 3, mais ils sont pratiquement tous compatible Rails 2.

Le code source des exemples est disponible sur ce github.

(Lire la suite…)

« 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…)