Se débarrasser d'un cauchemar vivant lors des tests

À propos de l'auteur

Après son apprentissage en tant que développeur d'applications, Ramona contribue depuis plus de 5 ans au développement de produits chez shopware AG : Première en…
En savoir plus sur
Ramona
↬

Il y a une fable à laquelle je pense beaucoup ces jours-ci. La fable m'a été racontée lorsque j'étais enfant. Il s’appelle «Le garçon qui criait au loup» par Aesop. Il s'agit d'un garçon qui s'occupe des moutons de son village. Il s'ennuie et prétend qu'un loup attaque le troupeau, appelant les villageois à l'aide – seulement pour qu'ils réalisent avec déception qu'il s'agit d'une fausse alerte et laissent le garçon tranquille. Puis, lorsqu'un loup apparaît et que le garçon appelle à l'aide, les villageois croient que c'est une autre fausse alerte et ne viennent pas à la rescousse, et les moutons finissent par être mangés par le loup.

La morale de l'histoire est mieux résumé par l'auteur lui-même:

«Un menteur ne sera pas cru, même s'il dit la vérité.»

Un loup attaque le mouton, et le garçon crie à l'aide, mais après de nombreux mensonges, personne ne croit lui plus. Cette morale peut être appliquée aux tests: l'histoire d'Esope est une belle allégorie pour un modèle de correspondance sur lequel je suis tombé par hasard: des tests floconneux qui ne fournissent aucune valeur. les jours sont consacrés aux tests frontaux. Cela ne devrait donc pas vous surprendre que les exemples de code de cet article proviendront principalement des tests frontaux que j'ai rencontrés dans mon travail. Cependant, dans la plupart des cas, ils peuvent être facilement traduits dans d'autres langues et appliqués à d'autres frameworks. J'espère donc que cet article vous sera utile – quelle que soit votre expertise.

Il vaut la peine de rappeler ce que signifie le test frontal. Dans son essence, les tests frontaux sont un ensemble de pratiques pour tester l'interface utilisateur d'une application Web, y compris ses fonctionnalités.

En tant qu'ingénieur en assurance qualité, je connais la douleur des tests manuels sans fin à partir d'une liste de contrôle. avant une libération. Ainsi, en plus de l’objectif de garantir qu’une application reste exempte d’erreurs lors des mises à jour successives, je me suis efforcé de alléger la charge de travail des tests causés par ces tâches de routine pour lesquelles vous n’avez pas besoin d’un humain. Maintenant, en tant que développeur, je trouve le sujet toujours pertinent, d'autant plus que j'essaie d'aider directement les utilisateurs et les collègues. Et il y a un problème avec les tests en particulier qui nous a donné des cauchemars.

La science des tests floconneux

Un test floconneux est un test qui ne parvient pas à produire le même résultat à chaque fois que la même analyse est exécutée. La construction n'échouera qu'occasionnellement: une fois elle passera, une autre fois échouera, la prochaine fois passera à nouveau, sans qu'aucune modification n'ait été apportée à la construction.

esprit. C'était dans un test d'interface utilisateur. Nous avons construit une liste déroulante de style personnalisé (c'est-à-dire une liste sélectionnable avec un champ de saisie):

Avec cette liste déroulante, vous pouvez rechercher un produit et sélectionner un ou plusieurs résultats. Plusieurs jours, ce test s'est bien passé, mais à un moment donné, les choses ont changé. Dans l'une des quelque dix versions de notre système d'intégration continue (CI), le test de recherche et de sélection d'un produit dans cette zone de liste déroulante a échoué.

La capture d'écran de l'échec montre que la liste des résultats n'est pas filtrée, bien que la recherche ait réussi:

Un test irrégulier comme celui-ci peut bloquer le pipeline de déploiement continu rendant la livraison des fonctionnalités plus lente que nécessaire. De plus, un test floconneux est problématique car il n'est plus déterministe, ce qui le rend inutile. Après tout, vous ne feriez pas plus confiance à personne qu’à un menteur.

De plus, les tests irréguliers sont coûteux à réparer nécessitant souvent des heures voire des jours pour déboguer. Même si les tests de bout en bout sont plus enclins à être floconneux, je les ai expérimentés dans toutes sortes de tests: tests unitaires, tests fonctionnels, tests de bout en bout, et tout ce qui se trouve entre les deux.

Un autre problème important avec des tests floconneux est l'attitude qu'ils imprègnent en nous les développeurs. Quand j'ai commencé à travailler dans l'automatisation des tests, j'ai souvent entendu les développeurs dire ceci en réponse à un test échoué:

«Ahh, cette version. Tant pis, recommencez. Cela finira par passer, un moment. »

C'est un énorme drapeau rouge pour moi . Cela me montre que l'erreur de construction ne sera pas prise au sérieux. Il y a une hypothèse qu'un test floconneux n'est pas un vrai bogue, mais est «juste» floconneux, sans avoir besoin d'être pris en charge ou même débogué. Le test passera à nouveau plus tard de toute façon, non? Nan! Si un tel commit est fusionné, dans le pire des cas, nous aurons un nouveau test floconneux dans le produit.

Les causes

Ainsi, les tests floconneux sont problématiques. Que devons-nous faire à leur sujet? Eh bien, si nous connaissons le problème, nous pouvons concevoir une contre-stratégie.

Je rencontre souvent des causes dans la vie de tous les jours. Ils peuvent être trouvés dans les tests eux-mêmes . Les tests peuvent être rédigés de manière sous-optimale, contenir de fausses hypothèses ou contenir de mauvaises pratiques. Cependant, pas seulement cela. Les tests irréguliers peuvent être une indication de quelque chose de bien pire.

Dans les sections suivantes, nous passerons en revue les plus courants que j'ai rencontrés.

1. Causes côté test

Dans un monde idéal, l'état initial de votre application doit être parfait et prévisible à 100%. En réalité, vous ne savez jamais si l’identifiant que vous avez utilisé lors de votre test sera toujours le même.

Examinons deux exemples d’un seul échec de ma part. L'erreur numéro un était en utilisant un ID dans mes montages de test:

 {
   "id": "f1d2554b0ce847cd82f3ac9bd1c0dfca",
   "name": "Variant product",
}

L'erreur numéro deux était de rechercher un sélecteur unique à utiliser dans un test d'interface utilisateur et de penser: «Ok, cet identifiant semble unique. Je vais l'utiliser. »

Cependant, si j'exécute le test sur une autre installation ou, plus tard, sur plusieurs versions de CI, ces tests peuvent échouer. Notre application générerait à nouveau les ID, en les changeant entre les versions. Ainsi, la première cause possible se trouve dans ID codés en dur .

La deuxième cause peut provenir de données de démonstration générées au hasard (ou autrement) . Bien sûr, vous pensez peut-être que cette «faille» est justifiée – après tout, la génération de données est aléatoire – mais pensez à déboguer ces données. Il peut être très difficile de voir si un bogue est dans les tests eux-mêmes ou dans les données de démonstration.

Ensuite, il y a une cause côté test avec laquelle j'ai lutté à maintes reprises: tests avec interdépendances . Certains tests peuvent ne pas être en mesure de s'exécuter indépendamment ou dans un ordre aléatoire, ce qui est problématique. De plus, les tests précédents pourraient interférer avec les tests suivants. Ces scénarios peuvent provoquer des tests irréguliers en introduisant des effets secondaires.

Cependant, n'oubliez pas que les tests consistent à remettre en question les hypothèses . Que se passe-t-il si vos hypothèses sont erronées au départ? J'en ai souvent fait l'expérience, ma préférée étant des hypothèses erronées sur le temps.

Un exemple est l'utilisation de temps d'attente inexacts, en particulier dans les tests d'interface utilisateur – par exemple, en utilisant des temps d'attente fixes . La ligne suivante est tirée d'un test Nightwatch.js .

 // Veuillez ne jamais faire cela à moins d'avoir une très bonne raison!
// Attend 1 seconde
browser.pause (1000);

Une autre hypothèse erronée concerne le temps lui-même. Une fois, j'ai découvert qu'un test floconneux PHPUnit échouait uniquement dans nos versions nocturnes. Après quelques débogages, j'ai trouvé que le décalage horaire entre hier et aujourd'hui était le coupable. Un autre bon exemple est celui des échecs dus aux fuseaux horaires .

Les fausses hypothèses ne s'arrêtent pas là. Nous pouvons également avoir des hypothèses erronées sur l'ordre des données . Imaginez une grille ou une liste contenant plusieurs entrées avec des informations, comme une liste de devises:

Nous voulons travailler avec les informations de la première entrée, la devise «couronne tchèque». Pouvez-vous être sûr que votre application placera toujours cette donnée comme première entrée à chaque fois que votre test est exécuté? Se pourrait-il que l '«euro» ou une autre devise soit la première entrée à certaines occasions?

Ne partez pas du principe que vos données arriveront dans l'ordre dont vous en avez besoin. Comme pour les identifiants codés en dur, un ordre peut changer entre les versions, selon la conception de l'application.

2. Causes côté environnement

La catégorie suivante de causes concerne tout ce qui est en dehors de vos tests. Plus précisément, nous parlons de l'environnement dans lequel les tests sont exécutés, des dépendances liées au CI et au docker en dehors de vos tests – toutes ces choses que vous pouvez à peine influencer, du moins dans votre rôle de testeur.

A des fuites de ressources : il s'agirait souvent d'une application sous charge, provoquant des temps de chargement variables ou un comportement inattendu. Les tests volumineux peuvent facilement provoquer des fuites, consommant beaucoup de mémoire. Un autre problème courant est le manque de nettoyage .

L'incompatibilité entre les dépendances me donne des cauchemars en particulier. Un cauchemar s'est produit lorsque je travaillais avec Nightwatch.js pour tester l'interface utilisateur. Nightwatch.js utilise WebDriver, qui dépend bien sûr de Chrome. Lorsque Chrome a fait un sprint avec une mise à jour, il y avait un problème de compatibilité: Chrome, WebDriver et Nightwatch.js ne fonctionnaient plus ensemble, ce qui faisait échouer nos builds de temps en temps.

En parlant de dépendances : Une mention honorable va à tous les problèmes de npm, tels que les permissions manquantes ou la panne de npm. J'ai expérimenté tout cela en observant CI.

Quand il s'agit d'erreurs dans les tests d'interface utilisateur dues à des problèmes environnementaux, gardez à l'esprit que vous avez besoin de toute la pile d'applications pour qu'elles fonctionnent. Plus il y a de choses en jeu, plus il y a de potentiel d'erreur . Les tests JavaScript sont donc les tests les plus difficiles à stabiliser dans le développement Web, car ils couvrent une grande quantité de code.

3. Causes côté produit

Dernier point mais non le moindre, nous devons vraiment faire attention à ce troisième domaine – un domaine avec de vrais bugs. Je parle des causes de floconnage côté produit. L'un des exemples les plus connus est les conditions de course dans une application. Lorsque cela se produit, le bogue doit être corrigé dans le produit, pas dans le test! Essayer de corriger le test ou l'environnement n'aura aucune utilité dans ce cas.

Moyens de lutter contre la floculation

Nous avons identifié trois causes de flakiness. Nous pouvons construire notre contre-stratégie là-dessus! Bien sûr, vous aurez déjà beaucoup gagné en gardant les trois causes à l'esprit lorsque vous rencontrez des tests irréguliers. Vous saurez déjà ce qu'il faut rechercher et comment améliorer les tests. Cependant, en plus de cela, il existe des stratégies qui nous aideront à concevoir, écrire et déboguer des tests, et nous les examinerons ensemble dans les sections suivantes.

Focus sur votre équipe

Votre équipe est sans doute la facteur le plus important . Dans un premier temps, admettez que vous avez un problème avec les tests irréguliers. Obtenir l’engagement de toute l’équipe est crucial! Ensuite, en équipe, vous devez décider comment gérer les tests irréguliers.

Au cours des années où j'ai travaillé dans la technologie, je suis tombé sur quatre stratégies utilisées par les équipes pour contrer la fragilité:

1. Ne rien faire et accepter le test irrégulier
   Bien entendu, cette stratégie n'est pas du tout une solution. Le test ne rapportera aucune valeur parce que vous ne pouvez plus lui faire confiance, même si vous acceptez le floconnage. Nous pouvons donc sauter celui-ci assez rapidement.
2. Réessayez le test jusqu'à ce qu'il réussisse.
   Cette stratégie était courante au début de ma carrière, ce qui a donné lieu à la réponse que j'ai mentionnée plus tôt. Il y avait une certaine acceptation avec de nouvelles tentatives de tests jusqu'à ce qu'ils réussissent. Cette stratégie ne nécessite pas de débogage, mais elle est paresseuse. En plus de masquer les symptômes du problème, cela ralentira encore plus votre suite de tests, ce qui rend la solution non viable. Cependant, il peut y avoir quelques exceptions à cette règle, que j'expliquerai plus tard.
3. Supprimez et oubliez le test.
   Celui-ci est explicite: supprimez simplement le test irrégulier, pour qu'il ne le fasse pas perturber votre suite de tests. Bien sûr, cela vous fera économiser de l'argent car vous n'aurez plus besoin de déboguer et de corriger le test. Mais cela se fait au détriment de la perte d'un peu de couverture de test et de la perte de corrections de bogues potentielles. Le test existe pour une raison! Ne tirez pas sur le messager en supprimant le test.
4. Mettre en quarantaine et corriger.
   J'ai eu le plus de succès avec cette stratégie. Dans ce cas, nous sauterions temporairement le test et demanderions à la suite de tests de nous rappeler constamment qu'un test a été ignoré. Pour nous assurer que le correctif n'est pas oublié, nous planifierons un ticket pour le prochain sprint. Les rappels de bot fonctionnent également bien. Une fois que le problème à l'origine de la fragilité a été résolu, nous intégrerons à nouveau (c'est-à-dire annulerons) le test. Malheureusement, nous perdrons temporairement la couverture, mais cela reviendra avec un correctif, donc cela ne prendra pas longtemps.

Ces stratégies nous aident à résoudre les problèmes de test au niveau du workflow, et je ne suis pas le seul à les avoir rencontrés. Dans son article, Sam Saffron arrive à la même conclusion . Mais dans notre travail quotidien, ils nous aident dans une mesure limitée. Alors, comment procéder lorsqu'une telle tâche se présente?

Gardez les tests isolés

Lorsque vous planifiez vos cas de test et votre structure, gardez toujours vos tests isolés des autres tests, afin qu'ils puissent être exécutés dans un ordre indépendant ou aléatoire. L'étape la plus importante est de restaurer une installation propre entre les tests . En outre, testez uniquement le flux de travail que vous souhaitez tester et créez des données factices uniquement pour le test lui-même. Un autre avantage de ce raccourci est qu'il améliorera les performances des tests . Si vous suivez ces points, aucun effet secondaire d'autres tests ou données restantes ne vous gênera.

L'exemple ci-dessous est tiré des tests d'interface utilisateur d'une plate-forme de commerce électronique et traite de la connexion du client dans la boutique. vitrine. (Le test est écrit en JavaScript, en utilisant le framework Cypress .)

 // Fichier: customer-login.spec.js
laissez le client = {};

beforeEach (() => {
    // Définit l'application sur l'état de nettoyage
    cy.setInitialState ()
      .then (() => {
        // Créer des données de test pour le test spécifiquement
        return cy.setFixture ('client');
      })
}):

La première étape consiste à réinitialiser l'application sur une installation propre. Il s’agit de la première étape du crochet de cycle de vie beforeEach pour s’assurer que la réinitialisation est exécutée à chaque fois. Ensuite, les données de test sont créées spécifiquement pour le test – pour ce cas de test, un client serait créé via une commande personnalisée. Par la suite, nous pouvons commencer avec le flux de travail que nous voulons tester: la connexion du client.

Optimiser davantage la structure de test

Nous pouvons faire quelques autres petits ajustements pour rendre notre structure de test plus stable. Le premier est assez simple: commencez par des tests plus petits. Comme indiqué précédemment, plus vous en faites dans un test, plus cela peut mal tourner. Gardez les tests aussi simples que possible et évitez beaucoup de logique dans chacun.

Quand il s'agit de ne pas supposer un ordre de données (par exemple, lorsqu'il s'agit de l'ordre des entrées dans une liste dans les tests d'interface utilisateur), nous pouvons concevoir un test pour qu'il fonctionne indépendamment de tout ordre. Pour ramener l'exemple de la grille contenant des informations, nous n'utiliserions pas de pseudo-sélecteurs ou d'autres CSS qui ont une forte dépendance à l'ordre. Au lieu du sélecteur nth-child (3) nous pourrions utiliser du texte ou d'autres choses pour lesquelles l'ordre n'a pas d'importance. Par exemple, nous pourrions utiliser une assertion comme «Trouvez-moi l'élément avec cette seule chaîne de texte dans ce tableau».

Attendez!

Réessayer les tests est un sujet controversé, et à juste titre. Je pense toujours à cela comme un anti-modèle si le test est réessayé aveuglément jusqu'à ce qu'il réussisse. Cependant, il existe une exception importante: lorsque vous ne pouvez pas contrôler les erreurs, une nouvelle tentative peut être un dernier recours (par exemple, pour exclure les erreurs des dépendances externes). Dans ce cas, nous ne pouvons pas influencer la source de l'erreur. Cependant, soyez très prudent lorsque vous faites ceci: ne devenez pas aveugle à la fragilité lorsque vous réessayez un test, et utilisez les notifications pour vous rappeler quand un test est ignoré.

L'exemple suivant est celui que j'ai utilisé dans notre CI avec GitLab. D'autres environnements peuvent avoir une syntaxe différente pour effectuer des tentatives, mais cela devrait vous donner un avant-goût:

 test:
    script: rspec
    recommencez:
        max: 2
        quand: runner_system_failure

Dans cet exemple, nous configurons le nombre de tentatives à effectuer si le travail échoue. Ce qui est intéressant, c’est la possibilité de réessayer en cas d’erreur dans le système d’exécution (par exemple, la configuration du travail a échoué). Nous choisissons de réessayer notre travail uniquement si quelque chose dans la configuration du docker échoue.

Notez que cela réessayera tout le travail lorsqu'il sera déclenché. Si vous souhaitez réessayer uniquement le test défectueux, vous devrez rechercher une fonctionnalité dans votre infrastructure de test pour le prendre en charge. Voici un exemple de Cypress, qui a pris en charge la relance d'un seul test depuis la version 5:

 {
    "retries": {
        // Configurer les tentatives de relance pour «Cypress run»
        "runMode": 2,
        // Configurer les tentatives de relance pour 'cyprès ouvert'
        "openMode": 2,
    }
}

Vous pouvez activer les tentatives de test dans le fichier de configuration de Cypress, cypress.json . Là, vous pouvez définir les tentatives de relance dans le lanceur de tests et en mode sans tête.

Utilisation des temps d'attente dynamiques

Ce point est important pour toutes sortes de tests, mais particulièrement pour les tests d'interface utilisateur. Je ne saurais trop insister sur ce point: N'utilisez jamais de délais d'attente fixes – du moins pas sans une très bonne raison. Si vous le faites, considérez les résultats possibles. Dans le meilleur des cas, vous choisirez des temps d'attente trop longs, ce qui ralentira la suite de tests. Dans le pire des cas, vous n’attendez pas assez longtemps. Le test ne se poursuivra donc pas car l’application n’est pas encore prête, ce qui entraîne l’échec du test de manière irrégulière. D'après mon expérience, c'est la cause la plus courante des tests irréguliers.

Utilisez plutôt des temps d'attente dynamiques. Il existe de nombreuses façons de le faire, mais Cypress les gère particulièrement bien.

Toutes les commandes Cypress possèdent une méthode d'attente implicite: elles vérifient déjà si l'élément auquel la commande est appliquée existe dans le DOM pour le temps spécifié. à la capacité de réessai de Cypress. Cependant, il ne vérifie que l'existence et rien de plus. Je recommande donc d'aller plus loin – attendre les changements dans l'interface utilisateur de votre site Web ou de votre application qu'un utilisateur réel verrait également, comme des changements dans l'interface utilisateur elle-même ou dans l'animation.

Cet exemple utilise un temps d'attente explicite sur l'élément avec le sélecteur .offcanvas . Le test ne se poursuivra que si l'élément est visible jusqu'au délai spécifié, que vous pouvez configurer:

 // Attendre les modifications dans l'interface utilisateur (jusqu'à ce que l'élément soit visible)
cy.get (#element) .should ('être.visible');

Une autre possibilité intéressante dans Cypress pour l'attente dynamique est ses fonctionnalités réseau. Oui, nous pouvons attendre les demandes et les résultats de leurs réponses. J'utilise ce genre d'attente particulièrement souvent. Dans l'exemple ci-dessous, nous définissons la requête à attendre, utilisons une commande wait pour attendre la réponse et affirmons son code d'état:

 // File: checkout-info.spec.js

// Définit la demande à attendre
cy.intercept ({
    url: '/ widgets / client / info',
    méthode: 'GET'
}). as ('checkoutAvailable');

// Imaginez d'autres étapes de test ici ...

// Affirme le code d'état de la réponse de la requête
cy.wait ('@ checkoutAvailable'). its ('response.statusCode')
  .should ("égal", 200);

De cette façon, nous sommes en mesure d'attendre exactement aussi longtemps que notre application a besoin, ce qui rend les tests plus stables et moins sujets aux flocons dus à des fuites de ressources ou à d'autres problèmes environnementaux.

Débogage des tests Flaky

Nous maintenant savoir comment éviter les tests irréguliers de par leur conception. Mais que se passe-t-il si vous êtes déjà confronté à un test irrégulier? Comment pouvez-vous vous en débarrasser?

Quand je déboguais, mettre le test défectueux en boucle m'a beaucoup aidé à découvrir les défauts. Par exemple, si vous exécutez un test 50 fois et qu'il réussit à chaque fois, vous pouvez être plus certain que le test est stable – peut-être que votre correctif a fonctionné. Sinon, vous pouvez au moins avoir plus d'informations sur le test floconneux.

 // Utilisez dans la construction Lodash pour répéter le test 100 fois
Cyprès ._. Fois (100, (k) => {
    it (`en tapant bonjour $ {k + 1} / 100`, () => {
        // Écrivez vos étapes de test ici
    })
})

Obtenir plus d'informations sur ce test floconneux est particulièrement difficile en CI. Pour obtenir de l'aide, voyez si votre framework de test est en mesure d'obtenir plus d'informations sur votre build. En ce qui concerne les tests frontaux, vous pouvez généralement utiliser un console.log dans vos tests:

 it ('should be a Vue.JS component', () => {
    // Composant simulé par une méthode définie avant
    wrapper const = createWrapper ();


    // Imprimez le code HTML du composant
    console.log (wrapper.html ());

    expect (wrapper.isVueInstance ()). toBe (true);
})

Cet exemple est tiré d'un test unitaire Jest dans lequel j'utilise un console.log pour obtenir la sortie du HTML du composant testé. Si vous utilisez cette possibilité de journalisation dans le testeur de Cypress, vous pouvez même inspecter la sortie dans les outils de développement de votre choix. De plus, en ce qui concerne Cypress in CI, vous pouvez inspecter cette sortie dans le journal de votre CI en utilisant un plugin.

Regardez toujours les fonctionnalités de votre framework de test pour obtenir de l'aide avec la journalisation. Dans les tests d'interface utilisateur, la plupart des frameworks fournissent des fonctionnalités de capture d'écran – au moins en cas d'échec, une capture d'écran sera prise automatiquement. Certains frameworks fournissent même un enregistrement vidéo ce qui peut être d'une grande aide pour avoir un aperçu de ce qui se passe dans votre test. en les empêchant en premier lieu ou en les déboguant et en les corrigeant dès qu'ils se produisent. Nous devons les prendre au sérieux, car ils peuvent faire allusion à des problèmes dans votre application.

Repérer les drapeaux rouges

Éviter les tests irréguliers en premier lieu est bien sûr le mieux. Pour récapituler rapidement, voici quelques signaux d'alarme:

• Le test est volumineux et contient beaucoup de logique.
• Le test couvre beaucoup de code (par exemple, dans les tests d'interface utilisateur).
• Le test utilise
• Le test dépend des tests précédents.
• Le test affirme des données qui ne sont pas prévisibles à 100%, comme l'utilisation d'identifiants, d'heures ou de données de démonstration, en particulier celles générées aléatoirement.

Si vous gardez à l'esprit les pointeurs et stratégies de cet article, vous pouvez éviter les tests irréguliers avant qu'ils ne se produisent. Et s'ils arrivent, vous saurez comment les déboguer et les corriger.

Ces étapes m'ont vraiment aidé à reprendre confiance en notre suite de tests. Notre suite de tests semble stable pour le moment. Il pourrait y avoir des problèmes à l'avenir – rien n'est parfait à 100%. Cette connaissance et ces stratégies m'aideront à y faire face. Ainsi, je deviendrai confiant dans ma capacité à combattre ces cauchemars de test floconneux .

J'espère avoir été en mesure de soulager au moins une partie de votre douleur et de vos inquiétudes au sujet de la desquamation!

Lectures complémentaires

] Si vous voulez en savoir plus sur ce sujet, voici quelques ressources et articles intéressants qui m'ont beaucoup aidé:

(vf, il, al)