Étiquette : tests

AssertJ pour des assertions plus expressives

Écrire des tests, c’est bien, écrire des bons tests c’est encore mieux. La technique given when then est une des bonnes pratiques pour écrire des tests (unitaires ou pas d’ailleurs). Les 3 concepts sont en effet nécessaires, y-compris le dernier qui correspond aux assertions. En effet, un test n’apporte vraiment de la valeur que si il procède à des vérifications sur le résultat de son exécution. Ça parait évident mais je suis tombé à plusieurs reprises sur des tests qui exécutaient du code sans rien vérifier…

En Java, les outils de base les plus populaires pour écrire des tests (JUnit et TestNG) sont assez pauvres pour écrire les assertions. Heureusement, il existe des outils permettant de gagner à la fois en puissance et en expressivité pour exprimer les assertions. Continuer la lecture de AssertJ pour des assertions plus expressives

Mock ou pas mock ?

C’est quoi un mock ?

Avant de rentrer dans le vif du sujet, il me semble important de faire une mise au point sur les concepts dont je vais parler dans cet article.

Dans le jargon du développeur, le mot mock a tendance à être utilisé à toutes les sauces. Martin Fowler, dans l’article Mocks Aren’t Stubs, parle de différents concepts :

  • Test double : objet factice qui prétend être l’objet attendu mais dont le comportement est adapté spécifiquement aux besoins du test. Le mot double fait allusion à la doublure au cinéma. Le mot mock est souvent utilisé dans ce sens-là.
  • Dummy : objet demandé par l’API qu’on teste mais qui n’est pas utilisé lors de l’exécution du code.
  • Fake : objet qui remplit le contrat (interface) mais dont l’implémentation peut faire abstraction de certaines contraintes, ce qui fait qu’il n’est pas adapté à la production (les bases de données en mémoire en sont un bon exemple).
  • Stub : objet au comportement éventuellement configurable qui peut ne répondre que très partiellement au contrat qu’il est censé remplir. Souvent écrit spécifiquement pour un ou ensemble de tests, il peut parfois enregistrer les interactions qu’on a avec lui dans l’objectif de les vérifier par la suite.
  • Mock : objet magique au comportement pré-câblé très spécifique. Dans la plupart des langages il est nécessaire d’utiliser un outil pour générer ce genre d’objets, cet outil permettant souvent de configurer au moment de l’exécution le comportement de l’objet sous la forme : «quand on te demande ça tu fais ça».

Continuer la lecture de Mock ou pas mock ?

Puis-je avoir confiance en mes tests ?

Il existe un certain nombre d’outils permettant de fournir des métriques qui visent à mesurer la qualité d’un logiciel, notamment à travers l’analyse statique dont j’avais eu déjà l’occasion de parler. Ces métriques sont plus ou moins représentatives de la qualité du code. Mais nous permettent-elles de savoir si nous pouvons avoir confiance en notre code ?

Jusqu’à nouvel ordre, pour s’assurer que du code remplit correctement les besoins, nous n’avons pas vraiment d’autre solution que de le tester, et nous le faisons de manière aussi automatique que possible pour augmenter notre productivité. Mais nos tests sont-ils fiables ? Puis-je sortir une nouvelle version de mon produit en toute confiance ou dois-je croiser les doigts à chaque mise à jour ?

Il existe un certain nombre de façons permettant de savoir si nous pouvons avoir confiance en nos tests. Continuer la lecture de Puis-je avoir confiance en mes tests ?

Vos tests ont besoin d’amour

Vos tests ont besoin d'amourC’est le titre de la présentation que j’ai faite aujourd’hui à l’Agile Tour Aix Marseille.

Les slides de ma présentation sont disponibles ici. Pendant la présentation, j’ai cité plusieurs liens qui sont référencés sur ce slide.

La présentation est faite en HTML 5 avec Reveal.js. Son code source est disponible sur GitHub. Pour visualiser la présentation en plein écran, appuyez sur la touche f de votre clavier, tandis que la touche s vous permettra d’avoir accès à mes notes, ce qui vous donnera un peu plus d’informations à propos de ce que j’ai pu dire à l’oral pendant la présentation sur chaque diapo (les slides contiennent très peu de texte).

C’était ma première présentation dans une conférence et de mon côté l’expérience est concluante. Je la renouvellerai très certainement. J’ai eu de très bons retours (meilleurs que ce à quoi je m’attendais) qui m’ont confirmé que le sujet intéressait le public et que l’approche que j’ai choisie semble être assez bonne (plus pratique que théorique). N’hésitez pas à me faire d’autres retours au sujet de cette présentation en utilisant par exemple les commentaires de cet article.

Merci en tout cas à tous ceux qui y ont assisté. Je suis ravi si j’ai pu vous apprendre quelque chose ! Si vous avez des questions que vous n’avez pas pu me poser pendant la présentation ou qui vous sont venues depuis, n’hésitez pas à les poser en laissant un commentaire à cet article. Merci également aux organisateurs et partenaires qui ont œuvré pour que cette journée ait lieu.

L’image d’en-tête provient de Flickr.

La maturité face aux tests

En tant que discipline assez récente, le développement logiciel est un domaine qui se cherche encore en termes de technologies et de processus. Malgré tout, il y a un certain nombre de pratiques qui commencent à avoir fait leurs preuves et faire de plus en plus l’unanimité.

Pour ce qui concerne la maîtrise de la qualité des logiciels, il existe différentes techniques. La revue de code en fait partie, mais l’écriture de tests automatiques reste aujourd’hui la solution qui semble être la plus efficace et adaptée dans le cas général.

Pourtant, à mon goût, il y a bien trop peu de développeurs aujourd’hui qui écrivent des tests. J’ai essayé de classer les développeurs en quatre niveaux qui représentent leur maturité face aux tests. Comme toute analyse qui consiste à classer des individus dans des catégories, cette approche est forcément caricaturale. Continuer la lecture de La maturité face aux tests

Tester c’est douter

Je suis développeur depuis quelques années maintenant et je commence à avoir un peu d’expérience.  Je suis donc un bon développeur, fort et intelligent. Quand j’écris du code, il n’y a pas vraiment de raison pour qu’il ne fonctionne pas. En fait, je suis maintenant persuadé de la chose suivante :

Tester c’est douter

Continuer la lecture de Tester c’est douter