Qu'est-ce que le test unitaire, le test d'intégration, le test de fumée, le test de régression?
Qu'est-ce que test unitaire, test d'intégration, test de fumée, test de régression et quelles sont les différences entre eux? Et quels outils puis-je utiliser pour chacun d'eux?
Par exemple, j'utilise JUnit et NUnit pour les tests unitaires et les tests d'intégration. Existe-t-il des outils de test de fumée ou de test de régression?
Test unitaire: Spécifiez et testez un point du contrat de méthode unique d'une classe. Cela devrait avoir une portée très étroite et bien définie. Les dépendances complexes et les interactions avec le monde extérieur sont écrasées ou moquées .
Test d'intégration: teste le bon fonctionnement de plusieurs sous-systèmes. Il y a tout un spectre, du test d'intégration entre deux classes au test d'intégration avec l'environnement de production.
Smoke test (aka sanity check): test d'intégration simple dans lequel on vérifie que lorsque le système testé est appelé, il retourne normalement et ne explose pas.
- Le test de fumée est à la fois une analogie avec l’électronique, où le premier test a lieu lors de la mise sous tension d’un circuit (s’il fume, c’est mauvais!) ...
- ... et, apparemment , avec plomberie , où un système de canalisations est littéralement rempli de fumée, puis vérifié visuellement. Si quelque chose fume, le système a des fuites.
Test de régression: Un test écrit lors de la correction d'un bogue. Cela garantit que ce bogue spécifique ne se reproduira plus. Le nom complet est "test de non-régression". Il peut également s'agir d'un test effectué avant de modifier une application pour s'assurer que celle-ci produit le même résultat.
J'ajouterai à cela:
Test d'acceptation: Teste qu'une fonctionnalité ou un cas d'utilisation est correctement implémenté. Il est similaire à un test d'intégration, mais met l'accent sur le cas d'utilisation à fournir plutôt que sur les composants impliqués.
Test du système: teste un système comme une boîte noire. Les dépendances sur d'autres systèmes sont souvent simulées ou dégradées au cours du test (sinon, il s'agirait davantage d'un test d'intégration).
Vérification pré-vol: tests répétés dans un environnement de type production, pour atténuer le syndrome «s'appuie sur ma machine». Ceci est souvent réalisé en faisant un test d'acceptation ou de fumée dans un environnement de production tel que.
- Test unitaire : un test automatique pour tester le fonctionnement interne d'une classe. Il devrait s'agir d'un test indépendant qui n'est pas lié à d'autres ressources.
- Test d'intégration : test automatique effectué sur un environnement, similaire aux tests unitaires mais avec des ressources externes (db, accès disque).
- Test de régression : après avoir implémenté de nouvelles fonctionnalités ou des corrections de bugs, vous testez à nouveau des scénarios qui fonctionnaient auparavant. Ici, vous couvrez la possibilité dans laquelle vos nouvelles fonctionnalités casser des fonctionnalités existantes.
- Test de fumée : premiers tests sur lesquels les testeurs peuvent conclure s’ils continuent le test.
Tout le monde aura des définitions légèrement différentes, et il y a souvent des zones grises. Toutefois:
- Test unitaire: ce petit peu (aussi isolé que possible) fonctionne-t-il?
- Test d'intégration: ces deux composants (ou plus) fonctionnent-ils ensemble?
- Test de fumée: l'ensemble de ce système (aussi proche que possible d'un système de production) fonctionne-t-il assez bien ensemble? (c.-à-d. sommes-nous raisonnablement convaincus que cela ne créera pas de trou noir?)
- Test de régression: avons-nous réintroduit par inadvertance des bogues que nous avions précédemment corrigés?
Une nouvelle catégorie de tests dont je viens de prendre connaissance est la suivante:
Test des Canaries
UNE Test des Canaries est un test automatisé et non destructif exécuté régulièrement dans un environnement LIVE, de sorte que quelque chose de vraiment grave se produise.Des exemples pourraient être:
- Des données qui ne devraient jamais être disponibles que dans DEV/TEST sont-elles apparues dansLIVE.
- Est-ce qu'un processus en arrière-plan a échoué?
- Un utilisateur peut-il se connecter
anecdotes historiques apocryphes: les "tests de fumée" proviennent de l'ingénierie sous-marine (héritée de la plomberie) où de la fumée littérale serait pompée dans la coque pour voir si elle en ressortait, ce qui serait plutôt un échec dramatique pour un sous-marin!
Répondez depuis l’un des meilleurs sites Web de techniques de test logiciel:
Types de test logiciel - Liste complète Cliquez ici
C'est une description assez longue, je ne vais pas la coller ici: mais cela peut être utile pour quelqu'un qui veut connaître toutes les techniques de test.
J'espère que ça vous sera utile :)
Test unitaire: Vérification du composant particulier (c'est-à-dire de la classe) créé ou modifié des fonctions telles que conçues. Ce test peut être manuel ou automatisé mais ne dépasse pas la limite du composant.
Test d'intégration: Vérification que l'interaction de composants particuliers fonctionne comme prévu. Les tests d'intégration peuvent être effectués au niveau de l'unité ou du système. Ces tests peuvent être manuels ou automatisés.
Test de régression: Vérification que de nouveaux défauts ne sont pas introduits dans le code existant. Ces tests peuvent être manuels ou automatisés.
En fonction de votre SDLC (cascade, rup, agile, etc.), des tests particuliers peuvent être effectués par «phases» ou peuvent tous être effectués, plus ou moins, en même temps. Par exemple, les tests unitaires peuvent être limités aux développeurs qui transmettent ensuite le code aux testeurs pour les tests d'intégration et de régression. Cependant, une autre approche pourrait permettre aux développeurs d'effectuer des tests unitaires et un certain niveau de tests d'intégration et de régression (en utilisant une approche TDD avec intégration continue et tests unitaires et de régression automatisés).
L'ensemble d'outils dépendra en grande partie de la base de code, mais il existe de nombreux outils open source pour les tests unitaires (JUnit). Les solutions QTP (mercure) HP ou Silktest de Borland sont des outils d'intégration automatisés et de test de régression.
test unitaire : le test d'un module individuel ou d'un composant indépendant dans une application est connu pour être un test unitaire; les tests unitaires sont effectués par le développeur.
test d'intégration : combinant tous les modules et testant l'application pour vérifier la communication et le flux de données entre les modules fonctionnant correctement ou non, test effectué également par les développeurs.
test de fumée IN test de fumée vérifie l'application de manière superficielle et étendue. Lors du test de fumée, il vérifie la fonctionnalité principale de l'application. corrigera le défaut, le remettra à l'équipe de test et l'équipe de test vérifiera tous les modules pour vérifier si les modifications apportées dans un module affectent ou non l'autre module. EN TEST DE FUMÉE, les scénarios de test sont scriptés
test de régression l’exécution répétée des mêmes cas de test pour s’assurer que le module non modifié ne cause aucun défaut. Les tests de régression font partie des tests fonctionnels
LES TESTS DE RÉGRESSION-
"Un test de régression ré-exécute les tests précédents sur le logiciel modifié pour s'assurer que les modifications apportées au logiciel actuel n'affectent pas la fonctionnalité du logiciel existant."
Les tests unitaires concernent la plus petite partie possible de la mise en œuvre. En Java, cela signifie que vous testez une seule classe. Si la classe dépend d'autres classes, celles-ci sont falsifiées.
Lorsque votre test appelle plusieurs classes, il s’agit d’un test d’intégration.
Les suites de tests complètes peuvent prendre beaucoup de temps. Par conséquent, après un changement, de nombreuses équipes effectuent des tests rapides pour effectuer des tests afin de détecter les ruptures importantes. Par exemple, vous avez divisé les adresses URI en ressources essentielles. Ce sont les tests smoke.
Les tests de régression s'exécutent sur chaque version et vous permettent de procéder à une refactorisation efficace en analysant ce que vous cassez. Tout type de test peut être un test de régression, mais je trouve que les tests unitaires sont des plus utiles pour déterminer la source de l'erreur.
Test unitaire: Vérification du composant particulier (c'est-à-dire de la classe) créé ou modifié des fonctions telles que conçues. Ce test peut être manuel ou automatisé mais ne dépasse pas la limite du composant.
Test d'intégration: Vérification que l'interaction de composants particuliers fonctionne comme prévu. Les tests d'intégration peuvent être effectués au niveau de l'unité ou du système. Ces tests peuvent être manuels ou automatisés.
Test de régression: Vérification que de nouveaux défauts ne sont pas introduits dans le code existant. Ces tests peuvent être manuels ou automatisés.
En fonction de votre SDLC (cascade, rup, agile, etc.), des tests particuliers peuvent être effectués par «phases» ou peuvent tous être effectués, plus ou moins, en même temps. Par exemple, les tests unitaires peuvent être limités aux développeurs qui transmettent ensuite le code aux testeurs pour les tests d'intégration et de régression. Cependant, une autre approche pourrait permettre aux développeurs d'effectuer des tests unitaires et un certain niveau de tests d'intégration et de régression (en utilisant une approche TDD avec intégration continue et tests unitaires et de régression automatisés).
Un type de test qui semble mériter d’être mentionné dans ce fil de discussion est celui des tests de contrainte/performance/charge, qui pourrait simplement consister à déterminer les limites au-delà desquelles un certain logiciel cède sa place. Il convient de noter qu’en termes d’outillage, il est essentiel de déterminer avec précision la portée de ce que l’on propose de soumettre à une contrainte des tests dans une perspective système. Par exemple, dans le cas d’une "application Web", les tests de résistance peuvent inclure dans son champ l’application du serveur Web elle-même et l’outillage pourrait intervenir à cette fin . Voici un article de Nice sur test de charge http
Tests unitaires: Les tests unitaires sont généralement effectués par les développeurs, où les testeurs évoluent en partie dans ce type de tests, tests se faisant unité par unité . Dans Java Junit, il est également possible de tester des tests. si le code écrit est parfaitement conçu ou non.
Tests d'intégration: - Ce type de test est possible après les tests unitaires lorsque tous/certains composants sont intégrés.Ce type de test permet de s'assurer que, lorsque les composants sont intégrés, ils affectent les capacités de travail ou les fonctionnalistes des autres.
Test de fumée: - Ce type de test est effectué au dernier moment lorsque le système est correctement intégré et prêt à être utilisé sur le serveur de production . Ce type de test permet de s'assurer que toutes les fonctionnalités importantes du début à la fin fonctionnent correctement. et le système est prêt à être déployé sur le serveur de production.
Tests de régression: - Ce type de test est important pour vérifier que le système ne contient pas de défauts involontaires/non désirés lorsque le développeur corrige certains problèmes . Ce test permet également de s'assurer que tous les bogues sont résolus avec succès. qu'aucun autre problème ne s'est produit.
Les tests de fumée et de santé sont tous deux effectués après la création d'un logiciel pour déterminer s'il convient de commencer les tests. La santé mentale peut être exécutée ou non après un test de fumée. Ils peuvent être exécutés séparément ou en même temps - la raison étant immédiatement après la fumée.
Parce que les tests de cohérence sont plus approfondis et prennent plus de temps, dans la plupart des cas, ils méritent d'être automatisés.
Le test de fumée ne prend généralement pas plus de 5 à 30 minutes. Il est plus général: il vérifie un petit nombre de fonctionnalités de base de l’ensemble du système, afin de vérifier que la stabilité du logiciel est suffisante pour des tests ultérieurs et qu’il n’ya pas de problème, ce qui bloque le déroulement des cas de test planifiés.
Les tests de salubrité sont plus détaillés que la fumée et peuvent prendre de 15 minutes à une journée entière, selon l’ampleur de la nouvelle construction. Il s'agit d'un type de test d'acceptation plus spécialisé, exécuté après une progression ou un re-test. Il vérifie les fonctionnalités principales de certaines nouvelles fonctionnalités et/ou corrections de bugs, ainsi que certaines fonctionnalités étroitement liées à ces fonctionnalités, afin de vérifier leur fonctionnement selon la logique opérationnelle requise, avant que les tests de régression ne puissent être exécutés à plus grande échelle.
Je voulais juste ajouter et donner un peu plus de contexte sur pourquoi nous avons ces niveaux de test, ce qu’ils signifient vraiment avec des exemples
Dans son livre intitulé "Succeeding with Agile", Mike Cohn a proposé la "pyramide de test" comme moyen d’approcher des tests automatisés dans des projets. Il existe différentes interprétations de ce modèle. Le modèle explique quel type de tests automatisés doivent être créés, à quelle vitesse ils peuvent donner des informations sur l'application testée et qui écrit ces tests. Il y a essentiellement 3 niveaux de tests automatisés nécessaires pour chaque projet et ils sont les suivants.
Tests unitaires - Ils testent le plus petit composant de votre application logicielle. Cela pourrait littéralement être une fonction dans un code qui calcule une valeur en fonction de certaines entrées. Cette fonction fait partie de plusieurs autres fonctions de la base de code matériel/logiciel qui constitue l’application.
Par exemple - Prenons une application de calculatrice basée sur le Web. Les composants les plus petits de cette application devant être testés par unité pourraient être une fonction qui effectue l'addition, une autre qui effectue la soustraction, etc. Toutes ces petites fonctions réunies constituent l’application de la calculatrice.
Historiquement, le développeur écrit ces tests car ils sont généralement écrits dans le même langage de programmation que l'application logicielle. Des frameworks de tests unitaires tels que JUnit et NUnit (pour Java), MSTest (pour C # et .NET) et Jasmine/Mocha (pour JavaScript) sont utilisés à cette fin.
Le principal avantage des tests unitaires est qu'ils s'exécutent très rapidement sous l'interface utilisateur et que nous pouvons obtenir un retour rapide sur l'application. Cela devrait représenter plus de 50% de vos tests automatisés.
API/Tests d'intégration - Ils testent ensemble divers composants du système logiciel. Les composants peuvent inclure des bases de données de test, des API (Application Programming Interface), des outils et services tiers ainsi que l’application.
Par exemple - Dans notre exemple de calcul ci-dessus, l’application Web peut utiliser une base de données pour stocker des valeurs, utiliser des API pour effectuer des validations côté serveur et utiliser un outil/service tiers pour publier les résultats dans le cloud afin de les rendre accessibles à différents systèmes. plates-formes.
Historiquement, un développeur ou un technicien d'assurance technique rédigeait ces tests en utilisant divers outils tels que Postman, SoapUI, JMeter et d'autres outils tels que Testim.
Celles-ci fonctionnent beaucoup plus rapidement que les tests d'interface utilisateur car elles fonctionnent toujours sous le capot, mais peuvent prendre un peu plus de temps que les tests unitaires, car elles doivent vérifier la communication entre divers composants indépendants du système et garantir leur intégration transparente. Cela devrait comprendre plus de 30% des tests automatisés.
Tests d'interface utilisateur - Enfin, nous avons des tests qui valident l'interface utilisateur de l'application. Ces tests sont généralement écrits pour tester des flux de bout en bout dans l'application.
Par exemple - Dans l'application Calculatrice, un flux de bout en bout pourrait être, ouvrant le navigateur -> Saisie de l'URL de l'application Calculatrice -> Connexion avec nom d'utilisateur/mot de passe -> Ouverture de l'application Calculatrice -> Effectuer certaines opérations sur la calculatrice -> vérifier ces résultats à partir de l'interface utilisateur -> Se déconnecter de l'application. Cela pourrait être un flux de bout en bout qui serait un bon candidat pour l'automatisation de l'interface utilisateur.
L’Assurance Technique ou les testeurs manuels écrivent des tests d’interface utilisateur. Ils utilisent des infrastructures open source telles que Selenium ou des plateformes de test d'interface utilisateur telles que Testim pour créer, exécuter et gérer les tests. Ces tests donnent davantage de commentaires visuels car vous pouvez voir comment les tests fonctionnent, la différence entre les résultats attendus et réels à travers des captures d'écran, des journaux, des rapports de test.
La principale limite des tests d'interface utilisateur est qu'ils sont relativement lents par rapport aux tests unitaires et de niveau API. Ainsi, il ne devrait représenter que 10 à 20% de l'ensemble des tests automatisés.
Les deux types de tests suivants peuvent varier en fonction de votre projet, mais l’idée est-
Tests de fumée
Cela peut être une combinaison des 3 niveaux de test ci-dessus. L'idée est de l'exécuter à chaque enregistrement de code et de s'assurer que les fonctionnalités critiques du système fonctionnent toujours comme prévu. après la fusion des nouvelles modifications de code. Ils ont généralement besoin de fonctionner pendant 5 à 10 minutes pour obtenir un retour plus rapide sur les échecs.
Tests de régression
Ils sont généralement exécutés au moins une fois par jour et couvrent diverses fonctionnalités du système. Ils s'assurent que l'application fonctionne toujours comme prévu. Ce sont plus de détails que les tests de fumée et couvrent plus de scénarios de l'application, y compris les non critiques.
- Test d'intégration: le test d'intégration est l'intégration de l'autre élément
- Test de fumée: Le test de fumée est également appelé version de construction Testing. Le test de fumée est le processus de test initial utilisé pour vérifier si le logiciel testé est prêt/stable pour des tests supplémentaires.
- Test de régression: le test de régression est un test répété. Que le nouveau logiciel soit effectué dans un autre module ou non.
- Tests unitaires: C’est un test de la boîte blanche. Seuls les développeurs y participent
Une fois les tests terminés, les développeurs effectuent toujours des tests pour identifier les problèmes rencontrés par leur équipe de test avant de préparer des exigences pour le contrôle qualité.
Test d'intégration: Cela signifie que le testeur doit vérifier la vérification de module à sous-module lorsque certaines données/fonctions sont transmises à un module par un autre. Ou dans votre système si vous utilisez un outil tiers qui utilise les données de votre système pour l'intégration.
Test de fumée: test effectué pour vérifier que le système effectue des tests de haut niveau et pour essayer de détecter le bogue de show stopper avant que les modifications ou le code ne soit mis en ligne.
Test de régression: le testeur a effectué une régression pour vérifier les fonctionnalités existantes en raison des modifications apportées au système pour une nouvelle amélioration ou des modifications apportées au système.
Tests unitaires Les tests unitaires sont de niveau très bas, proche de la source de votre application. Ils consistent à tester des méthodes et des fonctions individuelles des classes, composants ou modules utilisés par votre logiciel. Unité les tests sont en général assez peu coûteux à automatiser et peuvent être exécutés très souvent rapidement par un serveur d'intégration continue.
Tests d'intégration Les tests d'intégration vérifient que différents modules ou les services utilisés par votre application fonctionnent bien ensemble. Par exemple, il peut tester l’interaction avec la base de données ou s’assurer que les microservices fonctionnent ensemble comme prévu. Ces types de tests sont plus coûteux à exécuter car ils nécessitent plusieurs parties de l'application à être opérationnel.
Tests fonctionnels Les tests fonctionnels sont axés sur les besoins de l'entreprise d'une application. Ils ne font que vérifier le résultat d’une action et ne le font pas vérifiez les états intermédiaires du système lorsque vous effectuez cette opération action.
Il y a parfois une confusion entre les tests d'intégration et tests fonctionnels car ils nécessitent tous deux plusieurs composants pour interagir avec l'un l'autre. La différence est qu'un test d'intégration peut simplement vérifiez que vous pouvez interroger la base de données pendant l’exécution d’un test fonctionnel attendez-vous à obtenir une valeur spécifique de la base de données telle que définie par le exigences du produit.
Tests de bout en bout Les tests de bout en bout reproduisent un comportement d'utilisateur avec le logiciel dans un environnement d'application complet. Il vérifie que divers flux d’utilisateurs fonctionnent comme prévu et peuvent être aussi simples que de charger un fichier page Web ou la connexion ou des scénarios beaucoup plus complexes de vérification des e-mails notifications, paiements en ligne, etc ...
Les tests de bout en bout sont très utiles, mais ils sont coûteux à réaliser et peut être difficile à maintenir quand ils sont automatisés. Il est recommandé de avoir quelques tests clés de bout en bout et se fier davantage aux types de niveau inférieur de tests (tests unitaires et d'intégration) pour pouvoir identifier rapidement briser les changements.
Tests d'acceptation Les tests d'acceptation sont des tests formels exécutés selon vérifier si un système répond à ses besoins opérationnels. Ils demandent l’ensemble de l’application doit être opérationnelle et se concentrer sur la réplication comportements des utilisateurs. Mais ils peuvent aussi aller plus loin et mesurer le performances du système et rejeter les modifications si certains objectifs ne le sont pas rencontré.
Tests de performances Les tests de performances vérifient les comportements du système lorsqu'il est soumis à une charge importante. Ces tests sont non-fonctionnel et peut avoir différentes formes pour comprendre le fiabilité, stabilité et disponibilité de la plate-forme. Pour Par exemple, il peut s’agir d’observer les temps de réponse lors de l’exécution d’un nombre élevé de nombre de demandes, ou voir comment le système se comporte avec un significatif de données.
Les tests de performance sont par nature assez coûteux à mettre en œuvre et exécuter, mais ils peuvent vous aider à comprendre si de nouveaux changements vont se produire dégrader votre système.
Test de fumée Les tests de fumée sont des tests de base qui vérifient les tests de base fonctionnalité de l'application. Ils sont censés être rapides à exécuter, et leur but est de vous donner l’assurance que le majeur les fonctionnalités de votre système fonctionnent comme prévu.
Les tests de fumée peuvent être utiles juste après qu'une nouvelle construction est faite pour décider si vous pouvez ou non exécuter des tests plus coûteux, ou juste après un déploiement pour s’assurer que l’application fonctionne correctement dans l'environnement nouvellement déployé.
source: https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testing
Test de régression - Il s’agit d’un type de test logiciel au cours duquel nous essayons de couvrir ou de vérifier le correctif du bogue. la fonctionnalité autour du correctif ne doit pas être modifiée ni altérée en raison du correctif fourni. Les problèmes rencontrés dans ce processus s'appellent des problèmes de régression.
Test de fumée: Est-ce une sorte de test effectué pour décider d'accepter la version/le logiciel pour un test d'assurance qualité plus poussé.
Quelques bonnes réponses déjà mais je voudrais les affiner davantage:
Le test unitaire est la seule forme de test de la boîte blanche ici. Les autres sont des tests de boîte noire. Le test de la boîte blanche signifie que vous connaissez l'entrée, vous connaissez le fonctionnement interne du mécanisme et pouvez l'inspecter, ainsi que la sortie. Avec le test de la boîte noire, vous ne savez que l’entrée et la sortie.
Il est donc clair que le test unitaire est le seul test de la boîte blanche ici.
- Le test unitaire teste des morceaux de code spécifiques. Généralement méthodes.
- Les tests d'intégration testent si votre nouvelle fonctionnalité peut s'intégrer à tout le reste.
- Les tests de régression. Ceci est fait pour vérifier que vous n'avez rien cassé. Tout ce qui fonctionnait auparavant devrait toujours fonctionner.
- Le test de fumée est fait comme un test rapide pour s'assurer que tout semble aller bien avant de vous lancer dans des tests plus vigoureux.
Le test de fumée a déjà été expliqué ici et est simple. Le test de régression est en cours de test d'intégration.
Les tests automatisés peuvent être divisés en seulement 2.
Test unitaire et test d'intégration. (c'est tout ce qui compte)
J'appellerais utiliser l'expression "test long" (LT) pour tous les tests tels que le test d'intégration, le test fonctionnel, le test de régression, le test d'interface utilisateur, etc. Et le test unitaire comme "test court".
Un exemple LT pourrait être, le chargement automatique d’une page Web, la connexion au compte et l’achat d’un livre. Si le test réussit, il est plus probable que celui-ci fonctionne sur un site actif de la même manière (d'où la référence «meilleur sommeil»). Long = distance entre la page Web (début) et la base de données (fin).
Et c’est un excellent article sur les avantages de test d’intégration (test long) par rapport au test unitaire } _
De manière simplifiée.
Test unitaire: Testez un seul élément de code, d'algorithme, de classe ou de système. Ce test doit être indépendant et les dépendances doivent être moquées ou tronquées.
Test d'intégration: doit vérifier si le composant, l'algorithme, la classe ou le système fonctionne correctement lorsqu'il est utilisé par d'autres composants. Les tests d'intégration ne servent pas à tester le fonctionnement du système (comportement), mais à vérifier si le système fonctionne correctement.
Smoke test: est un très petit ensemble de tests qui doit d'abord exécuter un grand nombre de tests. Il s'assurera simplement que les fonctionnalités les plus critiques du système fonctionnent même après une mise à niveau.
Test de régression: Processus consistant à tester les modifications apportées aux programmes informatiques pour s'assurer que la programmation plus ancienne fonctionne toujours avec les nouvelles modifications. Est-ce un plus grand ensemble de tests que les tests de fumée.
Si vous voulez en savoir plus sur le test d’intégration, vous pouvez aller à ce cours à Udemy, il offre un bon rabais.
https://www.udemy.com/testes-de-integracao-com-spring-boot/?couponCode=TISB_ODESC2019