Tests automatisés

Archi & techno

« pet vs. cattle », de l’artisan du serveur à l’artisan codeur

L’évolution du métier d’Ops suit un cheminement que nous observons régulièrement dans nos interventions. C’est au travers de cette fable, que nous allons voir les 4 étapes qui jalonnent ce chemin pavé d’embûches. Voyons pour cela comment un Ops procède concrètement pour effectuer l’opération « fix_mysql » qui consiste à changer une configuration de MySQL sur des serveurs de production.
cw_mfpdxcaugw_k
Lire la suite

Méthode

Sortir de la non qualité

Il y a quelques mois de cela, Michel vous parlait de la culture du Software Craftsmanship. Il évoquait notamment dans son article les différents enjeux à adresser pour diffuser cette culture dans l’entreprise. J’aimerais prolonger son discours en vous proposant de revenir sur l’origine de cet océan de code “legacy” dans lequel beaucoup d’entres nous naviguent douloureusement chaque jour. Mais surtout, j’aimerais vous proposer des moyens de s’en sortir.
Lire la suite

Archi & techno

La technique au service du Lean Startup

À 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

Archi & techno

Kinect, I mock you so much

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

Archi & techno

Tests par propriétés

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

Archi & techno

J’ai l’impression d’écrire mes tests en double !

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é ?

JUnit vs FitNesse

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

Archi & techno

Rails += Tests

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

Archi & techno

Automatiser ses tests de web services grâce à soapUI

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

Archi & techno

Des chiffres sur le ROI des tests unitaires

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