TDD

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…

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…

There is one major flaw you must have encountered whilst working with Silverlight for a while: its incompatibility with unit tests! Unless you’ve been using Silverlight solely for drawing circles and rectangles, surely you must have tried to use the Silverlight Toolkit unit test project template to try to put some TDD in your project ! ...most probably you were disappointed by it because it’s fairly poor...

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…

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 : https://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,…

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…