PIT : Une autre approche des tests unitaires

A l’occasion de la conférence Devoxx France édition 2014, une présentation a particulièrement retenu mon attention. Il s’agit de celle de PIT (Parallel Isolated Test), un outil de tests unitaires s’inscrivant dans les pratiques Test Driven Development (développement piloté par les tests) consistant à écrire les tests unitaires avant d’écrire le code source d’un logiciel. Ce sujet a été présenté durant la conférence sous forme d’un quickie d’une durée de quinze minutes par Alexandre Victoor, architecte technique à la Société Générale et ancien novédien.

PIT part du principe que le fait d’avoir une couverture de test des lignes ou des branches de code approchant les 100% ne garantit pas la qualité des tests. En effet, une couverture de tests nous informe uniquement sur ce qui n’est pas du tout testé mais pas sur la pertinence des tests. A l’inverse, PIT se veut qualitatif, plutôt que quantitatif, en essayant de mettre nos tests unitaires en défaut.

Lire la suite

Tests unitaires, d’intégration, fonctionnel, métier : comment les définir ?

Le champ sémantique de ces termes a évolué au fil du temps, conduisant à un certain flou et parfois des incompréhensions. Nous allons dans cet article apporter différents éclairages sur la terminologie du test, en espérant que cela pourra contribuer à une meilleure compréhension entre experts !

Situons le contexte

Le niveau processus

Un logiciel utilisé dans une entreprise a pour vocation de servir ses utilisateurs dans l’exécution des processus métier ou support. Au niveau le plus élevé, le fonctionnement d’une entreprise peut en général être décrit par des processus. Certains de ces processus ont pour objectif premier d’apporter de la valeur aux clients de l’entreprise (processus de commande et livraison, processus de service après vente, etc.), d’autres y contribuent moins directement mais restent pour autant nécessaires (processus d’approvisionnement, processus de paie des collaborateurs, etc.).

Ces processus sont caractérisés par des échelles de temps pouvant aller de quelques minutes à quelques années, l’ordre de grandeur typique étant de quelques jours. Ils font intervenir dans la majorité des cas plusieurs acteurs (de l’entreprise ou externes).

Le niveau cas d’utilisation

A certaines étapes de ces processus, un acteur sera susceptible d’utiliser un logiciel. Dans l’exemple du processus de commande et livraison, nous avons par exemple des étapes informatisées :

  • La prise de commande
  • La préparation de la commande
  • Le contrôle de la commande
  • L’expédition
  • La facturation

La plupart du temps, chacune de ces étapes correspondra à la notion de cas d’utilisation du logiciel. Le niveau de granularité est plus fin que pour le processus, et l’échelle de temps limitée à quelques minutes. Lorsqu’un cas d’utilisation a été déroulé à une étape du processus, l’étape suivante pourra être déclenchée immédiatement,  ou de manière asynchrone. Dans notre exemple, après la prise de commande, celle-ci est ajoutée dans la liste d’attente de l’entrepôt ou de l’atelier, et sera traitée dans un délai fonction de la charge de travail de ce service à l’instant présent. Lire la suite

soapUI et les tests de Web Services

SoapUI est un outil de test de Web Services développé par Eviware. Il existe en 2 versions dont une entièrement gratuite. Je le trouve très utile pour le debug et les tests unitaires de web services, mais aussi pour les tests automatisés et les tests de charge.

Je vous propose de découvrir dans cet article comment utiliser SoapUI pour réaliser des tests unitaires.

Lire la suite

Tests unitaires pour Google App Engine

google-app-engine Les développeurs Cloud le savent, tests unitaires et Google App Engine ne sont pas franchement compatibles : si on veut exécuter les tests unitaires sur le GAE depuis un script ou son IDE préféré, on est obligé de les invoquer via http (ou xmpp) et on est vite limité par le timeout de 30 secondes.

Le projet App Engine Unit tente de combler le vide. Le principe est de découper une suite de tests JUnit en tâches asynchrones et de les empiler ensuite dans la Task Queue.

Sur le papier, ça semble plutôt prometteur. Mais le projet en est encore à ses balbutiements (version 0.0.6 !). A suivre de près néanmoins.