Présentation

Formation qui prend la suite des tests unitaires. Elle traite de tout ce qui commence quand le code sort de son bocal : la base de données réelle, le service d’en face, la charge, l’attaquant, le navigateur.

Le parti pris est de comprendre les enjeux de chaque famille de tests plutôt que d’apprendre des API par cœur : savoir quel défaut un test de contrat attrape et qu’un test unitaire mocké laissera toujours passer vaut mieux que de réciter la syntaxe de l’outil du moment.

Elle complète la formation Tests logiciels en Python, qui couvre les tests unitaires, le TDD et la première mise en CI.

Public visé : développeurs et équipes techniques ayant déjà une pratique des tests unitaires et cherchant à couvrir l’intégration, la performance et la sécurité.

Prérequis : écrire des tests unitaires (pytest ou équivalent), lire un fichier de CI, notions de conteneurs.

Programme détaillé

Jour 1 — Cadrage, stratégie et intégration réaliste

Les limites du modèle en pyramide, les modèles alternatifs (testing trophy, microservices)
Choisir sa stratégie : grille de décision, anti-patterns fréquents
Ce qu’un test doit vérifier — et ce qu’il ne doit surtout pas figer
Architecture testable : isoler ce qui mérite de l’être
TestContainers : tester contre une vraie base, jetable et reproductible

Jour 2 — Contrat, performance et sécurité

Le bug que deux suites vertes laissent passer : la rupture de contrat entre services
Tests de contrat avec Pact : consumer-driven, broker, vérification côté fournisseur
Tests de performance avec k6 : charge, montée en charge, seuils et budget
Lire un résultat de charge sans se tromper de conclusion
Sécurité automatisée : SAST, DAST, SCA — trois familles, trois moments
OWASP Top 10 et baseline scan ZAP en ligne de commande

Jour 3 — End-to-end et pipeline complet

Playwright : sélecteurs robustes, attentes, isolation des tests
Le coût réel des tests end-to-end : combien en écrire, lesquels garder
Tests instables : diagnostiquer plutôt que relancer
Assembler la chaîne dans un pipeline GitLab : étages, parallélisme, rapports
Ce qui bloque une livraison et ce qui remonte en avertissement

Évaluation

QCM de révision en fin de parcours
TP par famille de tests sur une application fil rouge
Rendu final : une chaîne de test complète, exécutée en intégration continue

Modalités

Volume : 3 jours (adaptable — chaque famille de tests peut faire l’objet d’une journée isolée)
Format : présentiel ou distanciel
Supports : diaporamas, application fil rouge, kit de références par outil

Demander un devis

ou écrire directement, objet déjà rempli.