Étiquette : tests

Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Des conseils simples, avisés et … pragmatiques, pour bien commencer avec les tests unitaires.

Dans la veine des « starter kits » écrits par les « pragmatic programmers », voici un opuscule consacré aux tests unitaires en général et à JUnit en particulier. L’objectif est très clair : mettre le pied à l’étrier de manière pragmatique, sans s’encombrer de beaucoup de théorie. De fait le livre est court, avec 125 pages (hors annexes), mais quand même découpé en 9 chapitres, chacun étant donc court.
Le premier chapitre est une prose introductive au « pourquoi » des tests. Il s’étend largement sur les contre-arguments à leur écriture, et permet de balayer les objections les plus courantes. Toujours une bonne chose de faite. Au second chapitre, nous pratiquons l’équivalent du très classique « hello world ». C’est minimal et le chapitre est très court. Ce n’est pas le cas du chapitre 3 qui nous accoutume aux autres éléments utilisés classiquement lors de l’écriture de tests unitaires : setup, tear down, test suite et assertions en tout genre. Nous sommes armés pour écrire des tests plutôt standard mais qui répondent aux besoins courants.

A partir du chapitre 4, il est davantage question d’écrire de bons tests et une bonne couverture de test. Les auteurs proposent l’acronyme Right-BICEP. Tout d’abord il s’agit de définir ce qu’est un résultat juste, puis d’appliquer les règles du BICEP (que je ne vais pas développer ici). Toutefois le « B » pour boundary va être l’objet plus spécifiquement du chapitre 5 où il va être développé selon un autre acronyme, le CORRECT. Les conditions aux limites sont souvent source d’erreur, les auteurs font un bon travail à bien cerner l’ennemi. Le chapitre 6 est consacré aux Mock objects. Ce chapitre est juste une introduction au sujet, utilisant EasyMock, mais elle est consistante. Elle marque aussi la temporalité du livre, car l’exemple choisi est le mock d’une servlet !

Le chapitre 7 va aborder les propriétés d’un bon test et c’est l’occasion d’un nouvel acronyme : A-TRIP. Car si un test doit être Automatique, il doit aussi complet (Thorough) en testant ce qui peut casser, Répétable en remettant le système en conditions initiales en fin d’exécution, Indépendant en ne supposant pas de séquence d’exécution et enfin Professionnel ! Cette dernière propriété est énoncée de manière bien curieuse. Les auteurs veulent simplement dire que le code du test doit respecter les mêmes qualités de conception et d’implémentation que le code de production. Il n’y a guère de code au chapitre 8. Celui-ci est consacré à l’organisation du code de test et au cycle de développement. Rien que de très classique ici, puisque l’on organise le code façon Maven et que l’on préconise le test en continu sans toutefois aborder le TDD. Le livre se referme sur un chapitre 9 consacré à la conception, plus précisément aux implications du test unitaire sur la conception, ce que les auteurs appellent le « test-driven design ».

Continuer à lire « Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas » →

Note de lecture : Effective Software Testing, par Mauricio Aniche

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une stratégie de tests gravitant hélas uniquement autour des tests unitaires, mais faisant un excellent travail pour en systématiser l’approche.

En matière d’ingénierie logicielle moderne, la littérature sur les tests tend à se concentrer sur les tests unitaires et les tests d’acceptation. Les ouvrages qui englobent les pratiques de manières plus larges ciblent surtout l’aspect méthodologique. C’est donc avec intérêt que j’aborde ce texte qui se focalisent sur les différents types de tests que l’on peut mettre en œuvre au niveau des équipes de réalisation. Et nous allons le voir, cela ne se limite pas aux deux types de tests que nous venons d’évoquer.

Avec 274 pages hors annexes, cela reste un ouvrage de taille raisonnable. Il est structuré en 10 chapitres. Le premier chapitre annonce la couleur : les développeurs qui testent versus ceux qui ne testent pas. L’idée est ici d’avoir un tour d’horizon des types de tests qui vont être abordés et de l’aspect méthode et automatisation qui, même si on ne parle pas d’agilité, restent dans la même idée. Mon désaccord principal, sur ce chapitre et sur le livre, est d’utiliser la pyramide de tests comme boussole, une idée absolument dysfonctionnelle. Bien sûr, l’auteur met l’accent sur les petits tests qui s’exécutent rapidement (donc les tests unitaires), je ne saurais lui reprocher. Mais les autres tests sont pour lui : les tests d’intégration (quels tests d’intégration ?), les tests système et les tests manuels et c’est tout ! Pas de tests fonctionnels ou au moins de tests d’acceptation. C’est une vue erronée du paysage des tests, mais cela ne veut pas dire que l’ouvrage n’a pas d’intérêt.

En fait le chapitre 2 aborde le « specification-based testing ». Mais pas au sens des tests d’acceptation. Il s’agit ici de mettre en place des tests unitaires pour tester les règles de gestion à bas niveau. L’auteur y propose une démarche très systématique en 7 étapes allant des premiers tests passants aux tests aux limites puis « créatifs » sans oublier l’automatisation ! C’est de fait une approche très disciplinée des tests unitaires, peut-être trop, mais cela reste une très bonne source d’inspiration. Le texte ne s’arrête pas là puisqu’il aborde le traitement des bugs. Le propos est largement adossé à de très nombreux exemples en Java. Mais à mon avis l’illustration a travers de règles de validation sur une chaine de caractère n’est pas assez significatif d’un véritable projet.

Continuer à lire « Note de lecture : Effective Software Testing, par Mauricio Aniche » →

Note de lecture : Automatisation des activités de test, par Olivier Denoo, Marc Hage Chahine, Bruno Legeard & Eric Riou du Cosquer edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Des contributions assez hétéroclites autour de l’automatisation, mais parfois intéressantes !

Les ouvrages collectifs sont rarement de grandes réussites. Celui-ci n’échappe pas à la règle, avec des contributions assez inégales. Toutefois, je lui reconnaitrais le mérite d’associer à l’agilité la nécessité d’automatiser les tests !

Le format de l’ouvrage dépassera légèrement de votre bibliothèque. Fort de 220 pages imprimé sur papier glacé en couleur, il faut bien dire que le CFTL a bien fait les choses. Le texte tire parti de cette impression en couleur avec de très nombreuses illustrations, le volume s’avale plutôt rapidement. Le texte est divisé en 3 parties pour un total de 22 chapitres, chacun d’entre-eux est donc plutôt court. La première partie « l’automatisation dans le test » et compte 5 chapitres pour 53 pages. C’est un panel des pratiques d’automatisation que nous livre le 1er chapitre : court et bien fait, il ne nous apprend cependant guère de choses utiles.

Le second chapitre aborde le périmètre de ce qui peut automatisé dans les activités de test. On n’y apprend pas grand-chose non plus, mais cela a le mérite d’être écrit du point de vue du testeur, ce qui est original. Ainsi le panel des activités de test est bien décomposé, mais le propos reste assez stratosphérique. Le chapitre 3 sur le test et la démarche devops s’avère être l’un des plus intéressants de l’ouvrage. Ses 2 points forts sont l’accostage des différents types de test avec le pipeline CI/CD et la présentation du « shift left », le concept le plus intéressant et le plus original du livre !

Continuer à lire « Note de lecture : Automatisation des activités de test, par Olivier Denoo, Marc Hage Chahine, Bruno Legeard & Eric Riou du Cosquer edt. » →

Note de lecture : Effective methods for Software testing 2nd edition, par William E. Perry

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Une approche des tests très développée et d’une vision très large, mais présentée en cycle « V » classique…

Voilà le seul ouvrage traitant de tests « à l’ancienne » de ma bibliothèque. Cela rend ce volume d’autant plus important qu’il éclaire un pan de la culture test qu’il est nécessaire de comprendre. Dans le monde agile, les tests sont essentiels, et s’ils sont en majeure partie abordés différemment, comprendre cet écosystème reste un élément majeur pour aborder le changement.

Le livre est volumineux, certes, avec 800 pages mais ce n’est pas le plus volumineux publié dans le domaine. Au moins est-il bien rythmé avec 26 chapitres regroupés en 5 parties. A première d’entre-elles ne couvre qu’un seul chapitre sur une trentaine de pages. Son focus est l’évaluation des compétences et capacités de test. On y distingue l’évaluation du processus de test et l’évaluation des testeurs, le tout s’appuyant sur des corpus de connaissance entretenus par des organismes. Bref, on nage en plein dans les grilles d’audit. Cela ne fait guère envie mais au moins, on sait ce qui existe en la matière.

Avec 4 chapitres sur plus de 120 pages, la seconde partie est plus conséquente. Elle évoque la mise en place d’un environnement de test. Nous allons voir en quoi cela consiste. Le chapitre 2 adresse la stratégie de test, mais l’approche proposée, axée sur les phases de développement et les facteurs de risques ne se projette pas sur un cycle de développement agile. Dans la continuité, le chapitre 3 nous propose de construire une méthodologie de test, mais clairement axée sur un modèle en cascade, qui se conclut par un plan de test dont le template est passé en revue « in extenso ». Là non plus, rien de directement exploitable, mais il est riche d’enseignement de voir un véritable plan de test qui est souvent évoqué de manière bien abstraite.

Continuer à lire « Note de lecture : Effective methods for Software testing 2nd edition, par William E. Perry » →

Note de lecture : More Agile Testing, par Janet Gregory & Lisa Crispin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Pléthorique, mais toujours et encore trop verbeux.

Ce nouvel opus, de prime abord semble avoir pas mal de points communs avec le premier tome. Le plus important est la taille : ici encore il s’agit de 500 pages environ. Plutôt qu’une suite du premier volume, le thème serait plutôt « les auteurs n’ont pas tout dit » ! Si le volume précédent était majoritairement guidé par les cadrans de Brian Marrick, ici l’approche est plus thématique.

Le volume nous propose 25 chapitres, regroupés en 8 parties. La première d’entre-elle, sobrement intitulée « introduction » ne compte que 2 chapitres sur 25 pages. Le premier est consacré aux évolutions des pratiques durant les 10 années qui ont séparé les 2 volumes. Une synthèse juste et plutôt bien faite qui évoque par exemple le test d’applications mobiles ou les pratiques de test d’acceptation. Le second chapitre met un coup de zoom sur l’importance de la culture de l’organisation. C’est un aspect qui avait été peu (ou pas) évoqué précédemment.

La seconde partie « learning for better testing” va regrouper 4 chapitres sur un peu plus de 60 pages. Le chapitre 3 dédié aux rôles et compétences comprend des sujets tels que les profils généralistes versus spécialistes, donc bien sûr une évocation des profils en « I » et en « T » qui m’a toujours semblée un peu bateau et de la pluridisciplinarité. Donc, pas tant de choses nouvelles ou originales au final. Les « thinking skills » évoquées au chapitre m’ont semblées plus intéressantes : la facilitation, l’écoute, la connaissance du domaine pour n’en citer que quelques-uns sont replacés dans le contexte d’une activité de test. Une prose qui pourra s’avérer utile pour le recrutement de vos prochains testeurs.

Continuer à lire « Note de lecture : More Agile Testing, par Janet Gregory & Lisa Crispin » →

Note de lecture : Unit Testing : Principles, Practices and Patterns, par Vladimir Khorikov

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ;Des principes et des guidelines très solides pour concevoir les tests unitaires et les tests d’intégration.

Ce n’est pas le premier ouvrage sur les tests unitaires, bien loin s’en faut ! Mais c’est une belle surprise, même si elle bouscule un peu certaines de mes idées établies sur le sujet. Le but de l’auteur est de faire émerger et poser les principes sous-jacents à la pratique des tests unitaires. On pourrait penser que cela peut se contenter d’un mémoire de 50 pages au plus ? Il n’en est rien.

Au niveau du format, le livre rentre dans la moyenne : 270 pages sur 11 chapitres, le tout divisé en 3 parties inégales. . La première d’entre-elle nous dresse le paysage des tests unitaires sur un peu plus de 60 pages incluant 3 chapitres. La finalité des tests unitaires est l’objet des 20 pages du premier chapitre. C’est un début en douceur où est évoqué la question de l’entropie du code, mais où l’auteur s’attaque surtout au mythe de la couverture de code (à juste titre). Dommage que le mutation testing ne soit pas évoqué, ni ici ni plus tard.

Le second chapitre s’attaque à des principes fondamentaux : qu’est-ce qu’un test unitaire ? Une question moins simple qu’il n’y parait. Outre la granularité délimitant le test unitaire des tests d’intégration ou de bout en bout, c’est surtout le choix de l’école de pensée qui est en cause : école de Londres (parfois appelés tests solitaires) ou école classique ou de Chicago (parfois appelés tests sociaux). L’auteur ne fait pas mystère de sa préférence pour l’approcha classique, mais fait un excellent travail pour déterminer comment chaque approcha traite les différents types de dépendances. Le chapitre s’attaque à l’anatomie interne des tests unitaire. Il n’est guère surprenant que l’auteur fasse la promotion du pattern AAA (Arrange, Act, Assert). Il va plus loin en détaillant les bonnes pratiques sur chacun des volets pour améliorer la lisibilité et la maintenabilité des tests, pour ensuite adresser la question de leur paramétrage.

Continuer à lire « Note de lecture : Unit Testing : Principles, Practices and Patterns, par Vladimir Khorikov » →

Note de lecture : Testing Microservices with Mountebank, par Brandon Byars

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une guide d’utilisation de Mountebank par son créateur. Bien écrit, mais assez basique

Mountebank est un framework de test (encore un) bien adapté au test des microservices, utilisant comme l’auteur nous le développera, le principe de l’imposture ! Malheureusement pour moi, la bête s’utilise avec du code JavaScript (avec du Node.js pour être précis), un obstacle que je n’avais pas anticipé. Cela a certainement impacté la note, dommage car le principe de ce moteur de test qui permet de simuler les services environnant au runtime ouvre nombre de perspectives.

Reprenons au départ : le volume se présente sous forme d’un texte de près de 220 pages découpé en 3 parties totalisant 10 chapitres. La première partie « premières étapes » ne compte que 2 chapitres sur 40 pages. Le premier chapitre « testing microservices » campe le décor. Il positionne clairement cet outil sur le volet « end to end » et introduit les notions de prédicats et d’imposteurs qui seront clé par la suite. Le second chapitre est le « hello world » … mais il s’avère rapidement être plus que cela. Il commence doucement en requêtes curl et en json, mais bascule rapidement sur le JavaScript ! L’auteur brûle un peu les étapes.

La seconde partie compte 6 chapitres et s’étend sur 130 pages. C’est le gros de la troupe et il est d’ailleurs sobrement intitulé « using Mountebank ». Il s’ouvre au chapitre 3 par le concept de réponses préfabriquées (canned responses), ce qui nous amène aussi à évoquer les prédicats. C’est plutôt clair et bien illustré. Les prédicats sont justement le sujet du chapitre 4. On les aborde en commençant par les expressions régulières pour terminer avec le JSonpath en passant par les champs multivalués. Le chapitre est riche et clair la plupart du temps.

Continuer à lire « Note de lecture : Testing Microservices with Mountebank, par Brandon Byars » →

Note de lecture : Testing Java Microservices, par Alex Soto Bueno, Andy Gumbrecht & Jason Porter

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Très pertinent sur la stratégie et la mise en œuvre des tests, souvent moins sur la clarté des explications.

Voici un livre qui s’est fait attendre plusieurs années. Au début, il s’agissait de produire un texte consacré à Arquilian. Finalement, le contexte s’est élargi aux tests de microservices de manière plus générale, Arquilian continuant à se tailler la part du lion, mais d’autres outils de test complétant le paysage, comme nous le verrons.

L’ouvrage totalise 260 pages réparties en 10 chapitres. Cela donne une moyenne de taille par chapitre relativement raisonnable mais quand même un peu plus élevée que ce que j’apprécie généralement. On démarre fort logiquement par un premier chapitre très court pour introduire les microservices. Il s’agit de présenter l’architecture microservices au niveau conceptuel. Une présentation pas vraiment fameuse, avec une représentation qui ne me parle guère et une architecture s’éloignant un peu de celle de Newman et où j’aurais aimé une pincée d’architecture hexagonale.

Le second chapitre présente l’application de test, ou plutôt l’architecture de test, sur une petite trentaine de pages. En fait, les auteurs ont fait le choix de rassembler des architectures techniques différentes : Spring Boot, TomEE et WildFly Swarm. A l’exception du vidéo service sur Spring Boot, le reste s’adosse à Java EE 7 ! Un choix dépassé depuis longtemps, peut-être justifié par le fait que les auteurs sont employés de JBoss ou parce qu’initialement Arquilian était dédié à JEE ? Quoi qu’il en soit, ce choix aurait dû être abandonné, il y avait déjà fort à faire en se contentant de Spring Boot et cette multiplicité introduit une regrettable complexité et de la confusion.

Continuer à lire « Note de lecture : Testing Java Microservices, par Alex Soto Bueno, Andy Gumbrecht & Jason Porter » →

Note de lecture : Writing Great Specifications, par Kamil Nicieja

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Dans la continuité du « specification by example » de Gojko Adzic, mais bien moins brillant.

Cet ouvrage est dédié à l’écriture de cas de test en Gherkin. Mais pas n’importe comment. Il s’inscrit dans la continuité du « specification by example » de Gojko Adzic qui a d’ailleurs préfacé le livre. En fait d’écriture de cas de test, l’auteur préfère évoquer l’écriture de spécifications (le livre a d’ailleurs changé de titre en cours de route), comme son devancier.

Il y a des variantes à la grammaire Gherkin, l’auteur a fait le choix de cibler celle supportée par Cucumber, bien qu’il fasse allusion à d’autres outils de temps à autre. De toute manière, l’outil n’est pas le propos du texte, ni même l’implémentation des scénarios. C’est bien de leur écriture dont il est question. Pour cet objectif, le texte accuse 250 pages structurées en 11 chapitres réparties sur 2 parties. La première d’entre-elle, regroupe les 6 qui suivent l’introduction et occupe 140 pages.
L’introduction justement, est là pour camper le décor. Il s’agit d’un chapitre plutôt dense, puisqu’il accapare à lui seul 30 pages. L’auteur y développe les définitions qui seront utiles par la suite, les anti-patterns de spécification et surtout sa démarche SBE. Mais que tout cela est verbeux ! Malheureusement, il en sera de même pour la suite.

En ouverture de la 1ère partie « Writing executable specifications with examples », le chapitre 2 évoque sur un peu plus de 20 pages l’articulation entre la couche de spécification et la couche d’automatisation. L’objectif du propos n’est pas franchement clair. J’ai l’impression que l’auteur tente de faire une introduction au ralenti. La véritable introduction est au chapitre 3, elle nécessite 25 pages et introduit tout à fait convenablement la syntaxe et les règles d’écriture qu’y surimpose l’auteur. C’est bien, juste trop volubile par rapport à la quantité d’information délivrée.

Continuer à lire « Note de lecture : Writing Great Specifications, par Kamil Nicieja » →

Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 1 ; Une approche des tests à l’ancienne pour un texte récent et une cible complètement ratée.

Tests d’acceptation et User Acceptance Tests n’adressent pas pour moi la même finalité : Le premier est destiné à valider la conformité de ce qui a été réalisé par rapport à la spécification, tandis que le second se doit d’évaluer dans quelle mesure ce qui a été spécifié puis réalisé adresse l’expression de besoin initiale de l’utilisateur. Bref, l’UAT est là pour tester (indirectement) la spécification.

Il y a vraiment très peu de livres consacrés aux UATs. Celui-ci est en fait pratiquement le seul que j’ai pu identifier à ce seul thème. J’avais deux craintes avant même d’avoir ouvert ce livre : avais-je la même vu sur les UATs que les auteurs ? Et , étant donné l’origine très « corporate » du texte, n’allais-je pas rencontrer une approche très processus à l’ancienne ? Comme nous allons le voir, la réponse est hélas « oui » aux deux questions.

L’ouvrage n’est guère long, moins de 180 pages si l’on ne compte pas les inénarrables check-lists ou templates. Le tout est découpé en 10 chapitres pour reprendre son souffle. Moins de 20 pages en moyenne par chapitre, il n’en faudrait pas plus, car le style d’écriture n’est pas pensé pour être une partie de plaisir. Le premier chapitre n’a que peu à offrir, mais je m’arrête quand même sur deux points : d’abord le contexte considéré est bel et bien du cycle en V. Ensuite la définition du rôle de l’UAT semble correspondre à la mienne. Le second chapitre « the importance of UAT » en rajoute une couche sans apporter grand chose : toujours plus de processus, la contribution des différents rôles… tout cela est un peu creux. On revient sur la définition des UATs et cela deviens moins clair, entre la validation des spécifications et la satisfaction du besoin utilisateur. A ce stade, je doute que la distinction soit même claire pour les auteurs.

Continuer à lire « Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem » →