À ChooseYourBoss, un site d’emploi informatique, on fait du Lean Startup. Plus précisément, on applique la méthode du Build-Measure-Learn (Construire – Mesurer – Apprendre). Tous les jours on construit notre produit, on l’améliore. Mais une partie importante de celui-ci est un logiciel que l’on développe.

Bien évidemment tout ce que l’on développe est au service du produit ou de nos clients.

Notre but étant d’apprendre le plus possible et surtout le plus vite possible, nous avons mis en place un certain nombre de pratiques qui nous aident. Ce sont des pratiques tout ce qu’il y a de plus classique. Mais mises ensemble elles nous permettent de nous améliorer. Nous allons donc vous les décrire succinctement.

(Lire la suite…)

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

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

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

Pour tester des web services (REST/SOAP), je me suis demandé si je devais développer mon framework : des tests de contrats (tests des requêtes XML via un framework de test unitaire) et des  tests d’intégration (via Fitnesse/GreenPepper).
Pas forcément compliqué à mettre en place, mais rébarbatif et pouvant être sujet à erreurs (donc, d’éventuelles contraintes supplémentaires de maintenance).

Mes besoins : trouver un outil rapide à prendre en main et gratuit pour automatiser mes tests de web service. On m’avait parlé de soapUI, je voulais m’en faire une idée.

Dans cet article je vais, au travers d’un exemple, utiliser soapUI pour effectuer toutes les étapes nécessaires à l’élaboration de tests automatisés : tests unitaires de requêtes, tests fonctionnels, tests en intégration continue.
Nous allons donc mettre à l’épreuve soapUI dans le but de créer une suite de tests automatisés.
(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…)

L’un des points fondamentaux pour réaliser un test automatisé est de le rendre reproductible. L’un des critères pour qu’un test soit unitaire est qu’une seule méthode soit testée de façon isolée sans dépendre d’une base de données ou de tout autre système externe. Le moyen le plus efficace pour assurer ces deux caractéristiques est d’utiliser des mocks. Trop souvent, lorsqu’on prononce ces mots devant un client, des réactions de méfiance apparaissent : on a besoin de la base de données dans l’équipe, avec notre code ça n’est pas possible, c’est compliqué… L’objectif de ce billet est de montrer une architecture applicative minimale pour répondre à ce besoin.
(Lire la suite…)

Comment Toyota a révolutionné la technologie des presses mécaniques pour pousser une stratégie business jusqu’au bout, et 2 morales de cette histoire pour la DSI.

(Lire la suite…)