C’est votre 10eme itération, vous êtes en plein stand-up et Roger le nouveau ne sait toujours pas quel post-its prendre. Il faut dire que Roger n’arrête pas de vous demander quelle tâche de développement il doit prendre aujourd’hui.

Vous êtes tech –lead sur un nouveau projet et vous recherchez un nouveau framework de test en Javascript.

Vous êtes RH, et vous êtes en train de rédiger une fiche de poste pour ce curieux métier qu’est le « product owner ».

Vous êtes responsables produit d’une grande assurance et on vous demande de rédiger un backlog.

Vous avez envie d’en parler, venez le 27 Septembre à l’Apéro Agile !

Autour d’un verre, nous discuterons de l’état de l’Agile, de carrière, de pratiques, de techniques et de vos réussites.
Que vos équipes soient déjà Agiles, que vous soyez vous même praticien de longue date, ou que vous souhaitiez vous mettre à l’Agile prochainement, venez partager avec d’autres pratiquants vos problèmes du quotidien afin de les résoudre ensemble.

Pour venir à l’apéro agile, inscription ici.

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

Cette question se pose lorsqu’on se met au Test Driven Developpement (TDD). Deux origines possibles : la méthodologie n’a pas été suivie à la lettre et elle nous puni, ou bien nous essayons de faire du TDD sur du code existant, non testé. Dans les deux cas, vous avez un problème de conception.
(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…

UPDATE : Cette formation se déroulera finalement le 12 et 13 mai

Si vous êtes en train de lire ce post à 23h, au travail, devant votre écran d’ordinateur, à corriger les bugs de votre application dont vous aimeriez bien terminer la mise en production, alors sauvez vos qualités de vie, gagnez en sérénité, ne vous énervez plus contre vous-même, ni votre ordinateur, venez vous avez sûrement besoin d’une formation sur le développement piloté par les tests.

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

Le débat autour du ROI des tests unitaires et du TDD (Test Driven Development) ne date pas d’hier comme cet article du blog Octo de 2008 en témoigne :

http://blog.octo.com/le-roi-du-tdd/

Les questions soulevées sont somme-toute naturelles : même convaincu du bien fondé de cette démarche, il est toujours intéressant d’avoir une estimation de combien coûte cet investissement.
Idem lorsqu’on souhaite démarrer un projet en TDD, comment intégrer cette donnée dans le chiffrage ? Doit-on prévoir +20%, +100%, rien du tout ?
Les chiffres tangibles sont rares, aux questions « concrètement combien ça va me coûter en J/H ? Dans quelle proportion je vais réduire le nombre de bugs ? » on est souvent sans réponses.

Plusieurs études ont pourtant été menées sur le sujet, notamment par Microsoft. Ce dernier a publié en 2009 une étude intitulée “On the Effectiveness of Unit Test Automation at Microsoft”. Nous ferons ici un résumé des points à retenir.

(Lire la suite…)

Introduction

Derrière ce titre abscons se trouvent deux concepts qui mettent en application le principe du KISS dans le langage de programmation Python : écrire de la doc et mettre des tests dans des sources Python, c’est simple avec l’utilisation conjointe des docstrings et du module doctest. Le concept proposé ici est des plus simples : écrire un test unitaire pour un objet présente beaucoup de similitudes avec le fait d’écrire la documentation de ce même objet, en particulier si on y présente des exemples d’utilisation. Ainsi, en faisant d’une pierre deux coups, on gagne du temps et limite les écarts.

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