Questions d'entretien automatisation des tests

La réponse qu'ils veulent : le smoke sur le chemin critique — connexion, transaction principale — parce qu'il tourne à chaque build et rembourse immédiatement. Commencer par les cas limites ou un framework sophistiqué avant que le smoke existe, c'est de l'effort dans le mauvais ordre.

100 % de QUOI est la question. L'automatisation complète de la régression des flux stables, oui. Mais l'exploration, l'utilisabilité et les fonctionnalités qui changent vite résistent au scriptage — courir après un pourcentage là produit des tests fragiles et une couverture pire, pas plus de qualité.

Testez autour : un contournement en mode test ou un OTP fixe dans les environnements inférieurs, mockez le fournisseur SMS/e-mail et lisez le code depuis son API, et gardez une vérification manuelle du vrai flux par release. N'affaiblissez jamais la sécurité de production pour les tests.

Pour la stabilité de la mise en page sur des pages stables, oui — les diffs de captures d'écran attrapent le CSS cassé à moindre coût. Pour « est-ce que ça a l'air bien », non : les outils comparent des pixels à une référence, ils ne peuvent pas juger le design. Utilisez-les là où la référence elle-même change rarement.

La maintenance est le grand oublié — mises à jour de locators, chasses à l'instabilité, montées de version de framework mangent 20-30 % du temps d'automatisation pour toujours. Aussi l'infrastructure (minutes de grid/CI) et la taxe des fausses alertes : chaque build rouge instable coûte une investigation à quelqu'un.

Peut-être oui : une suite verte qui vous laisse livrer chaque semaine avec confiance fait son travail — c'est une assurance plus de la vitesse, pas juste un filet à bugs. Mais auditez-la : si elle n'échoue JAMAIS non plus, vérifiez que les assertions affirment réellement quelque chose.

Le driver parle les interfaces d'automatisation internes de Chrome, qui changent d'une version à l'autre — une paire incompatible échoue au démarrage de session ou, pire, se comporte mal subtilement. Selenium Manager télécharge maintenant automatiquement le driver correspondant, ce qui a tué une décennie de douleur de configuration.

Une seule connexion WebSocket persistante vers le navigateur au lieu d'une requête HTTP par commande — latence plus faible, et ça permet l'auto-attente et l'écoute d'événements. Cette différence architecturale est l'essentiel de pourquoi les tests Playwright sont moins instables.

Deux mouvements : localiser par la sémantique la plus stable disponible — rôles, labels, noms — et demander aux développeurs d'ajouter des test ids, ce qui est un changement d'une ligne par élément. Les équipes en ajoutent volontiers une fois le coût des locators instables visible.

Le texte change sans que personne ne prévienne la QA — « Sign in » devient « Log in » dans un ajustement du mardi et la suite passe au rouge. Bien pour un texte vraiment stable, dangereux pour tout ce que le marketing peut éditer.

Mesurablement, marginalement — négligeable à côté du temps de réseau et d'attente dans une vraie suite. Choisissez sur la lisibilité et la capacité, pas la micro-performance ; quiconque cite la vitesse comme raison principale répète un article de blog de 2012.

CSS le gère : .tab.active button.submit — vers le bas et basé sur les classes. Si « actif » n'était détectable que depuis le texte d'un enfant, c'est là que XPath entre. Expliquer la frontière est la vraie réponse.

Il garantit l'unicité sans comprendre la sémantique de votre app — l'outil ne peut pas savoir quels attributs sont stables. C'est un indice de départ, pas un locator. Réécrivez-le en fonction du sens avant qu'il n'entre dans le dépôt.

Il scanne le document plutôt qu'un chemin, mais sur de vraies pages la différence est du bruit. La justesse et la survie battent le coût de scan théorique à chaque fois.

Ignorez complètement l'id : localisez par rôle et nom accessible (getByRole('textbox', {name: 'Email'})), par association de label, ou par un conteneur stable plus une position de sens. L'id est un attribut, pas l'identité de l'élément.

Apportez la facture : « la casse de locators nous a coûté N builds rouges et X heures ce mois-ci ; data-testid, c'est une ligne par élément. » Les ingénieurs corrigent les coûts qu'ils voient. Proposez vous-même la convention de nommage pour que ce soit un copier-coller, pas un projet.

Cliquable avant les clics, visible avant les lectures, présence pour les vérifications d'existence, valeurs de texte/attribut pour les changements d'état, et invisibilité des spinners avant de continuer. Attendre la MAUVAISE condition — la présence quand il vous faut cliquable — est sa propre source d'instabilité.

Chaque action auto-attend l'actionnabilité — attaché, visible, stable, activé — donc 90 % des attentes explicites disparaissent. Vous attendez encore explicitement des états au niveau de l'app : données chargées, spinner parti, URL changée.

Rarement et honnêtement : déboguer en local, cadencer contre un système externe à débit limité, ou une fonctionnalité vraiment basée sur le temps comme un compte à rebours. En code de test committé, chacun mérite un commentaire expliquant pourquoi une condition ne pouvait pas l'exprimer.

Que ça traite le symptôme et ralentit chaque exécution future. Chaque instabilité a une vraie condition en course — trouvez-la, attendez-la. Proposez de faire un binôme sur une : convertir un sleep en condition prend généralement des minutes et enseigne le schéma.

Son Locator est une requête, pas un nœud détenu — page.locator() re-trouve l'élément à chaque action. Le findElement de Selenium renvoie le nœud lui-même. Cette différence de conception, c'est toute la classe de bugs qui apparaît ou disparaît.

En dernier recours ça marche, mais ça masque le vrai problème : vous avez agi avant que le re-rendu se stabilise. Attendre la fin de la mise à jour, puis re-trouver, corrige la cause — réessayer cache la course de timing.

Modélisez les composants, pas juste les pages : une NavBar, un SearchWidget, un tableau de données utilisé partout. Les classes de page composent alors les composants. Correspondre à la structure de l'app est le point ; « page » est un nommage historique.

Un pack de smoke de dix tests contre deux écrans n'a pas besoin de la cérémonie — localisez en ligne et restez simple. Le pattern gagne sa structure quand tests et pages se multiplient ; introduisez-le quand la duplication commence, pas le premier jour.

Une garde vérifiant que la page s'est bien chargée (échouer vite avec un message clair) est défendable — c'est une précondition, pas une vérification. Les assertions métier jamais : le test doit montrer ce qu'il prouve.

Ni l'un ni l'autre — une troisième couche : clients/helpers/fixtures. Les page objects reflètent l'UI ; les tests racontent les scénarios ; l'infrastructure de mise en place a son propre module. Trois couches propres, c'est la forme d'un framework maintenable.

Honnête, précis, actuel : « plus de vérifications au niveau API — trop de choses passent par l'UI », ou « des tests de contrat avant que la scission en microservices nous morde », ou « des factories de données de test plus tôt ; les fixtures partagées ont causé des collisions en parallèle ». Zéro regret se lit comme zéro expérience.

La vraie métrique de maintenabilité : cloner, mise en place en une commande, un test modèle à copier, des page objects trouvables par nom, un README avec le chemin doré. Si la réponse est « il me suit pendant une semaine », le framework est un fief personnel, pas de l'infrastructure.

Les scripts enregistrés s'ancrent à ce que l'enregistreur a vu — locators fragiles, données codées en dur, zéro réutilisation — donc ils cassent en masse au premier changement d'UI. Bien pour prototyper un flux ; inmaintenable comme suite.

Quand des non-programmeurs doivent écrire des tests — certains contextes d'entreprise et d'externalisation. Le coût est de construire et maintenir le moteur de mots-clés, ce qui dépasse généralement le fait d'enseigner les bases du code aux gens. Rarement le bon compromis aujourd'hui.

Les petits jeux couplés à la logique en ligne à côté du test (relisibles dans le même diff) ; les grandes matrices ou partagées dans des fichiers ; tout ce qui est spécifique à l'environnement dans les fixtures/config. La mauvaise réponse est un seul tableur géant que personne ne versionne avec le code qui le lit.

Le piloté par les données exécute VOS lignes choisies ; le basé sur les propriétés (Hypothesis, QuickCheck) génère des entrées contre un invariant et réduit les échecs à des cas minimaux. Complémentaires : vos limites plus son exploration.

Les vrais pipelines uniquement — verify-payment a vraiment besoin de create-order. Il saute les dépendants en cas d'échec, ce qui se lit proprement, mais il sérialise aussi les tests et casse l'indépendance ; en abuser transforme une suite en une chaîne fragile.

@BeforeTest enveloppe un bloc <test> du XML de la suite — une fois par bloc ; @BeforeMethod tourne avant chaque @Test. Le sens XML de « test » embrouille tout le monde une fois ; le connaître montre que vous avez réellement utilisé TestNG.

function/class/module/session. Les choses en portée session sont un état partagé : un seul navigateur réutilisé partout est rapide jusqu'à ce qu'un test le salisse et empoisonne le reste. Partagez les choses coûteuses immuables ; gardez l'état mutable en portée function.

Au lieu d'une BaseTest avec setUp faisant tout pour tout le monde, chaque test demande exactement ce dont il a besoin — un test n'ayant besoin que d'un client API ne paie pas pour un navigateur. Composition, dépendances explicites, pas de hiérarchie de classes fragile.

Le timing : à l'ère de JUnit 4, seul TestNG avait les data providers, les groups et le parallèle prêts à l'emploi — exactement ce dont les suites d'UI ont besoin. Une décennie de tutoriels et de modèles a suivi. L'inertie est une vraie force technique.

@ParameterizedTest avec des sources — @ValueSource, @CsvSource, @MethodSource. MethodSource est la correspondance la plus proche : une méthode renvoyant un flux d'arguments, chacun devenant une exécution nommée.

Chaque assertion souple s'évalue, enregistre son échec — et le test passe au vert. C'est le bug le plus silencieux du code de test, et c'est pourquoi certaines équipes enveloppent les assertions souples dans des helpers ou lintent pour un assertAll manquant.

expect.soft() dans Playwright — les échecs marquent le test comme échoué mais l'exécution continue ; le rapport les liste tous. Même idée, sans le piège d'assertAll, puisque le runner suit lui-même les échecs souples.

Mythe en tant que loi, sagesse en tant que smell : un COMPORTEMENT par test, qui peut demander plusieurs assertions pour être cerné. Douze assertions couvrant trois flux sont trois tests portant un seul nom.

Tout le monde en a vu : affirmer qu'une variable égale elle-même, affirmer dans un try qui avale, affirmer sur l'entrée au lieu du résultat. C'est pourquoi « ceci peut-il échouer ? » a sa place dans la revue de code de test — la valeur d'une suite est sa capacité à passer au rouge.

Exécutez-la en boucle — 50 fois, artefacts activés : captures d'écran, vidéo, trace. Le schéma d'échec raconte l'histoire : échoue seulement en parallèle = état partagé ; seulement en CI = environnement ; à des points aléatoires = timing. Les preuves d'abord, le correctif ensuite.

Reproduisez sous l'UI : martelez la même opération via l'API. Si le double débit apparaît sans navigateur impliqué, c'est le produit. La suite a juste fait son travail — ce constat est un rapport de bug, pas un correctif de test.

Vérifiez la couverture d'abord : certains couvrent des chemins critiques et ont besoin d'être corrigés ; certains sont redondants et PEUVENT partir — une suppression en connaissance de cause est un triage valide. La suppression en bloc lâche silencieusement une protection que vous redécouvrirez en production.

Faites que ça coûte quelque chose de visible : chaque test en quarantaine a un ticket, un responsable et un âge ; le compte est sur le dashboard d'équipe ; un plafond (« max 10, sinon on s'arrête et on corrige ») maintient la pression. Une quarantaine invisible grossit pour toujours.

Autour d'EXTERNES vraiment peu fiables que vous ne pouvez pas corriger — un sandbox tiers aux hoquets connus — cadrées à cette frontière, pas globales. Une nouvelle tentative globale sur tous les tests est un aveu que le rouge ne veut rien dire.

C'est intégré ET rapporté : les tests réessayés sont marqués « flaky » dans le rapport, ce qui est exactement le schéma honnête — autorisé, visible, impossible à ignorer. Adoptez la moitié reporting, pas juste la moitié nouvelle tentative.

Exécutez-la en ordre aléatoire (pytest-randomly, l'ordre Random de JUnit) et en parallèle — les échecs qui apparaissent sont votre carte de dépendances. Corrigez-les par fréquence d'échec ; chaque correctif révèle généralement le suivant.

Via l'UI, oui ; via l'API ou l'amorçage BD, des millisecondes. Partagez pour la vitesse les choses coûteuses immuables (un navigateur par worker) ; ne partagez jamais un état mutable. Lent-mais-honnête bat rapide-mais-emmêlé — et la mise en place via l'API vous donne les deux.

Préoccupation séparée : jeux de données amorcés/anonymisés dans un environnement dédié pour les tests de volume et de migration. Les tests fonctionnels continuent de créer leurs propres petites données ; ne les pointez jamais vers le gros jeu partagé « parce qu'il est là ».

Même discipline que la production : variables d'environnement ou un gestionnaire de secrets, injectés en CI — jamais dans le dépôt. Un mot de passe de test dans l'historique Git reste un mot de passe dans l'historique Git.

Options par ordre : un contournement d'auth réservé aux tests dans les environnements inférieurs (émis par le backend, gardé par un flag), une émission de token programmatique contre l'API de l'IdP, ou une vraie connexion UI par session mise en cache et réutilisée. Ne scriptez jamais l'UI de connexion du tiers par test.

Non — la couverture se déplace là où elle appartient : une spec de connexion dédiée (plus verrouillage, erreurs, se-souvenir-de-moi). Deux cents connexions incidentes n'ont jamais été de la couverture ; c'était de la répétition déguisée en couverture.

Moins que le folklore ne le dit : cas limites de rendu/CSS, saisies de date/fichier, APIs de presse-papiers et de permissions, les politiques de stockage et d'autoplay plus strictes de Safari. La logique métier presque jamais — c'est pourquoi la matrice cadrée est rationnelle, pas paresseuse.

Des configurations nommées dans playwright.config — chromium/firefox/webkit, ou « mobile Safari » avec un profil d'appareil, ou même « connecté vs invité ». Une base de test, N projects, en parallèle par défaut : la matrice sans scripting shell.

Grid : vous possédez l'infra — gratuit-ish mais vous patchez, scalez et déboguez. Cloud : coût par minute, zéro maintenance, vraies fermes d'appareils, vidéo/logs inclus. Les petites équipes s'en sortent presque toujours moins cher en cloud une fois les heures d'ingénieur chiffrées.

Un seul jar avec des rôles (router, distributor, node), support Docker natif, protocole W3C uniquement, meilleure UI et observabilité. L'ancien jonglage hub-jar/node-jar et les bizarreries JSON Wire ont disparu.

L'architecture : WebSocket persistant au lieu de HTTP par commande, et chaque action auto-attend l'actionnabilité (visible, stable, activé). Les attentes que vous écriviez à la main sont le comportement par défaut du protocole.

Seulement avec un moteur : douleur d'instabilité ou de vitesse que les attentes ne peuvent pas corriger, et alors de façon incrémentale — nouveaux tests en Playwright, ancienne suite gelée et rétrécissant. Les réécritures big-bang de suites qui marchent sont comment les équipes passent un an sur place.

Une équipe JS/TS testant une app web à origine unique, valorisant l'expérience de débogage et les tests de composants — Cypress y est délicieux. L'adéquation d'un outil dépend de la forme de votre app, pas de sa réputation sur Twitter.

Stubber window.open vers le même onglet, affirmer l'URL qui se serait ouverte, ou tester le contenu du second onglet comme sa propre visite. Faisable — mais si votre produit est vraiment multi-fenêtres, vous combattez le modèle de l'outil.

Les rapports lisibles n'ont pas besoin de Gherkin : de bons noms de test plus des reporters vous y amènent sans la lourdeur des définitions d'étapes. Adoptez Cucumber seulement si des non-ingénieurs vont collaborer sur les scénarios — c'est ça la fonctionnalité ; tout le reste est un costume.

Des étapes ultra-génériques (« When je clique sur "{string}" ») transforment le Gherkin en un pire langage de programmation ; des étapes quasi-identiques dupliquées empilent les conflits de regex. Les suites saines gardent les étapes au niveau métier et peu nombreuses.

Parce que ce ne sont pas des éléments <select> — ce sont des divs/ULs stylés. Select pilote l'API de l'élément natif. Pour les custom vous automatisez l'interaction : ouvrir, attendre les options, cliquer. Inspectez la balise d'abord ; elle décide de l'approche.

Il les dissout surtout : frameLocator() perce les iframes en ligne, les nouvelles pages arrivent comme des événements de contexte que vous attendez, les dialogs via page.on('dialog'). La cérémonie de changement est largement spécifique à Selenium.

L'existence est la vérification la plus faible. Vraies assertions : taille non nulle, type correct, et contenu — parsez le CSV/PDF et vérifiez que les lignes ou totaux correspondent aux données à l'écran. « Un fichier est apparu » a passé pendant qu'on exportait des ordures.

Fichier surdimensionné, zéro octet, mauvaise extension, type renommé (exe en jpg — le serveur vérifie-t-il le contenu ?), nom de fichier unicode, et double envoi du même téléversement. Les vérifications côté serveur sont celles pertinentes pour la sécurité.

Les traces toujours activées coûtent du temps et du stockage sur les exécutions vertes ; on-first-retry ne capture que quand quelque chose a échoué une fois — quasi gratuit et vous obtenez quand même l'artefact. Par défaut on-first-retry en CI ; full-on pour traquer un fantôme précis.

Artefacts par échec en ligne, historique d'échec (nouveau vs connu), tendances de durée, marqueurs d'instabilité, et le build/commit de l'app testée. Un compte sans artefacts est un tableau de scores ; les ingénieurs ont besoin d'une scène de crime.

La dérive d'environnement : dépendances de navigateur manquantes (utilisez les images officielles), différences headless-vs-headed, hypothèses de viewport, et la famine de ressources faisant fleurir les instabilités de timing. Épinglez les images et versions ; « ça marche sur ma machine » a une édition CI.

Le pack smoke/critique — oui, absolument bloquant. La régression complète — généralement gater les releases, pas chaque merge. La nuance : tout ce qui bloque doit être digne de confiance ; une seule instabilité tolérée dans la barrière et la barrière est du théâtre.

Rebase MON travail non poussé/local de branche pour une histoire linéaire propre ; merge pour tout ce qui est partagé. Règle d'or : ne jamais réécrire l'historique que d'autres ont récupéré. Dans les équipes en squash-merge la distinction se dissout surtout au moment de la PR de toute façon.

Récupérez d'abord, sermonnez après : le reflog (ou l'ancienne tête de la PR) a encore vos commits — cherry-pickez-les. Puis corrigez le process : branches protégées, pas de force-push sur le partagé, --force-with-lease si le force est vraiment nécessaire.

Le mode de défaillance s'inverse : le mauvais code applicatif échoue visiblement ; le mauvais code de test PASSE silencieusement — un menteur vert. Donc la priorité de revue se déplace vers la force des assertions et les risques de faux-passages plutôt que le style. Un test faux est pire que pas de test.

Choisissez les deux qui enseignent le plus (force des assertions, indépendance), corrigez-vous les broutilles, faites un binôme sur le schéma. Quinze commentaires enseignent la peur, pas le test. Le but est sa prochaine PR, pas la perfection de celle-ci.

Ce que les utilisateurs vivent réellement : parcours critiques de bout en bout, le câblage entre le front et le back, les régressions cassant la mise en page, la gestion de saisie spécifique au navigateur. Si la vérification a du sens avec l'écran éteint, elle appartient plus bas.

Par test, vrai — par suite, elle achète cette confiance à un coût brutal : lent, instable, échecs grossiers. La pyramide n'est pas une idéologie, c'est de l'économie : même couverture, signal plus rapide. Gardez l'E2E pour ce que seul l'E2E peut voir.

L'élément peut être EN train de disparaître — ou votre vérification tourne avant que l'effet de l'action se rende, passant contre l'ancien DOM. L'ancrage positif (« sauvegarde confirmée ») fixe le moment ; seulement alors l'absence veut dire quelque chose.

findElement lève (et brûle l'attente implicite) quand manquant ; findElements renvoie une liste vide instantanément. Pour les vérifications d'absence la version liste est à la fois plus rapide et sans exception — un idiome Selenium classique.

Il épingle l'élément trouvé — à tout re-rendu vous détenez un nœud périmé, et l'exception ne pointe nulle part près de la cause. Il optimise la partie pas chère (la recherche) au prix de la partie chère (le débogage).

Non — la cohérence bat la pureté dans une suite qui marche. Gardez le pattern, évitez @CacheLookup, et si l'équipe migre un jour d'outillage, c'est le moment naturel pour lâcher les proxies. Les réécritures ont besoin de meilleures raisons que le goût.

Alors deux oiseaux : signalez les labels/rôles manquants comme des constats d'accessibilité (ce sont de vrais bugs côté utilisateur) et localisez par le meilleur sens disponible en attendant. La douleur d'automatisation et la dette d'a11y sont généralement la même dette.

Le coût, pas le principe : « N builds rouges et X heures le mois dernier étaient de la casse de locator ; data-testid termine cette classe d'échec pour une ligne par élément — voici la convention de nommage prête à coller. » Les ingénieurs argumentent avec des opinions, pas avec des factures.

Les artefacts d'abord — capture d'écran, vidéo, trace racontent la plupart des histoires. Puis comparez les environnements : viewport, polices, locale, fuseau horaire, flags GPU. Reproduisez en local AVEC headless activé et le même viewport avant de toucher au test.

L'ancien headless était un build allégé séparé avec de vrais écarts de comportement ; le nouveau headless (—headless=new, désormais le chemin par défaut) est le vrai binaire Chrome sans UI — bien moins de différences. Si vous avez vérifié pour la dernière fois en 2021, le folklore est périmé.

Build/commit de l'app, environnement, navigateur+version, nombre de workers, et seed de données si aléatoire. La moitié des « échecs bizarres » s'expliquent par « attends, QUEL build était-ce ? » — rendez cette question impossible.

Rapportez-les distinctement : un échec de fixture marque les tests comme en erreur/bloqués, pas échoués — couleur différente, sens différent. Vingt « échecs » qui sont un seul environnement mort devraient se lire comme un incident, pas vingt bugs.

Interaction entre tests : état partagé, collision de données en parallèle, ou famine de ressources ralentissant les timings. Dichotomisez : exécutez le test qui échoue avec des ensembles voisins de plus en plus grands jusqu'à ce que la paire coupable émerge.

Viewport, fuseau horaire, locale, version de navigateur (conteneurs), lockfiles de dépendances, et données amorcées. Chaque variable non fixée est un futur « ça marche sur ma machine » à votre nom.

Construisez-les à partir de vraies réponses capturées, ré-enregistrez selon un calendrier, et laissez la vérification de contrat planifiée contre le sandbox attraper les changements de forme — son échec veut dire « mettez à jour les mocks et le code », ce qui est exactement l'alerte que vous voulez.

Parce que c'est là que les intégrations meurent réellement en production, et qu'aucun test de chemin nominal ne les touche. Votre nouvelle tentative, votre fallback et votre gestion d'erreur côté utilisateur n'existent que si un test les force à s'exécuter — les mocks rendent ces cas une seule ligne.

Masquez les régions dynamiques (dates, avatars, pubs), épinglez polices/viewport/animations désactivées, comparez perceptuellement plutôt qu'au pixel exact, et cadrez sur des composants plutôt que des pages entières. La discipline est de choisir QUOI capturer, pas l'outil.

Les composants (façon Storybook) sont plus serrés : petits diffs, blâme évident, références pas chères. Les pages entières attrapent les collisions d'intégration/mise en page entre composants. Les design systems obtiennent les deux — composants largement, quelques pages clés comme canaris.

Sélecteurs/test ids, mécanisme d'auth (connexion API possible ?), environnements et contrôle des données, docs d'API, feature flags, tests existants, et qui possède les correctifs. Ça prédit votre vélocité mieux que tout choix d'outil.

L'app est la documentation : explorez avec les devtools ouverts, lisez le trafic d'API, vérifiez l'analytique pour les vrais parcours principaux, et notez ce que vous observez comme des affirmations testables. Vos notes deviennent la spec que tout le monde corrige.

Les preuves : tests jamais échoués en un an couvrant du code inchangé, doublons de vérifications de couche inférieure, tests pour des fonctionnalités retirées. Auditez la couverture avant chaque coupe. Une suite où chaque test mérite son temps d'exécution bat une plus grosse qui a l'air honnête.

Tout le monde s'engage sur les standards, un responsable tournant surveille les dashboards et pilote la résorption. « Tout le monde le possède » sans nom attaché est comment naissent les nocturnes de trois heures — les valeurs partagées ont besoin d'une seule personne responsable, gentiment.

Lire les artefacts (trace/capture) → reproduire le comportement PRODUIT à la main ou par API → échoue : ouvrir le bug avec la trace attachée ; cassé : corriger le test maintenant ou mettre en quarantaine avec un ticket. Le rouge n'est jamais ignoré et jamais auto-relancé dans le silence.

Le passeur silencieux — un test cassé s'annonce au moins. Un test qui ne peut pas échouer est de la valeur négative : il dépense du temps d'exécution à fabriquer une fausse confiance. C'est pourquoi « ceci peut-il échouer ? » est une question de revue.

Chacun a tout l'historique en local — vous pouvez committer, brancher et voir l'historique hors ligne, et il n'y a pas de point unique de défaillance. Vous synchronisez avec le remote quand vous êtes prêt, pas à chaque opération.

Sur votre propre branche de fonctionnalité avant d'ouvrir une PR — rejouez par-dessus le dernier main pour un historique propre et linéaire et résolvez les conflits une fois. Gardez-le aux branches que vous seul avez.

Pull/rebase sur main fréquemment pour que votre branche ne dérive pas, gardez les changements petits et ciblés, et coordonnez quand deux personnes doivent toucher le même fichier. Les branches à longue durée de vie sont des usines à conflits.

Un rebase interactif pour les squasher, réordonner ou reformuler en une séquence propre — sur votre propre branche uniquement. Présentez un historique lisible pour la revue, pas le flux brut de commits « wip ».

Avant de rebaser, ou quand vous voulez relire les changements entrants (git log origin/main) avant qu'ils touchent votre branche — pour qu'une intégration soit une étape délibérée, pas automatique.