2026 Checklist pièges front-end :
Cypress WebKit vs Safari sur Mac distant
Les équipes louent un Mac distant pour des navigateurs natifs Apple, puis prennent Cypress WebKit pour une preuve du comportement Safari. Cet écart livre des bugs de mise en page et de médias pendant que la vidéo remplit les SSD partagés. Ci-dessous : un tableau des écarts Safari, les chemins de cache, les interrupteurs vidéo et captures, les workers et seuils de retry, et trois étapes d’acceptation. Pour le contexte WebKit, voir la matrice Vitest/jsdom vs Safari et les tests Playwright WebKit sur Mac distant.
01 Cypress + WebKit : scénarios d’usage pertinents
Cypress WebKit convient lorsque vous voulez couvrir la régression sur la pile WebKit macOS tout en restant dans les API Cypress, avec Chromium et WebKit sur une même image Apple Silicon. C’est cohérent pour les SPA à sélecteurs stables et des parcours de durée moyenne.
Ne vous reposez pas uniquement sur lui pour les produits centrés vidéo, les scénarios de stockage stricts ou les interfaces WebGL lourdes où le WebKit d’automatisation diverge du build Safari que montrent vos analytics : gardez Cypress rapide et ajoutez une fumée Safari.app sur le même hôte.
02 Tableau des écarts : Cypress WebKit et Safari réel
Trois pièges fréquents. (1) Fausse confiance : des runs WebKit verts manquent ITP, le mode économie d’énergie et certains codecs. (2) Coût vidéo : l’enregistrement permanent sature les Mini partagés. (3) Retries sans budget : les flakies disparaissent des tableaux de bord. Cypress WebKit embarque le moteur fourni par Cypress ; Safari.app est le navigateur du Dock — planifiez avec le tableau suivant.
| Dimension | Cypress WebKit (Mac distant) | Safari.app (même machine) | En pratique |
|---|---|---|---|
| Alignement moteur | Bundle WebKit d’automatisation figé par Cypress | Safari système avec son propre rythme de version | Alignez la branche majeure sur votre cohorte analytics principale |
| GPU et composition | Pile Metal réelle, headed ou headful selon config | Session utilisateur complète, effets WindowServer | Revérifiez HDR, vidéo plein écran et canvas après les passes auto |
| Lecture auto et médias | Politique proche de WebKit, pas identique à la navigation manuelle | Gestes utilisateur, mode économie, onglet en arrière-plan | Un parcours manuel pour OTT et webinaires |
| ITP et cookies | Exerce les chemins de stockage WebKit | Règles anti-pistage cross-site telles qu’expédiées | Validez la persistance de session après reset ITP simulé |
03 Mac distant : chemins de cache des binaires navigateur et paramètres d’installation
Cache par défaut : ~/Library/Caches/Cypress. Sur des pools de Mac distants partagés, définissez CYPRESS_CACHE_FOLDER ; exécutez npx cypress install lors de la cuisson d’image ; vérifiez l’existence du dossier avant de paralléliser les specs. Journalisez la version Cypress, le chemin WebKit et l’espace libre — visez environ 200 Go libres si la vidéo est activée. Pour le tri des journaux d’échec, croisez avec régression E2E et triage des logs sur Mac distant.
- Figez paquet, lockfile et clé de cache ; isolez le cache par locataire sur hôtes partagés.
- Fumée : une spec qui log la famille du navigateur ; purge des vidéos après sept jours.
Runbook en cinq points avant de paralléliser WebKit :
- Exporter
CYPRESS_CACHE_FOLDERdans le fichier d’environnement CI et créer le répertoire avec les droits du runner. - Lancer
npx cypress verifyaprès install pour échouer vite si les binaires sont incomplets. - Enregistrer le nom et la version
cy.browsersur la première ligne de log pour les audits. - Monter les artefacts sur un chemin indexé par
GITHUB_SHA(ou équivalent) pour éviter d’écraser les vidéos entre relances. - Planifier une purge hebdomadaire qui ne supprime que les fichiers plus anciens que votre règle de rétention.
04 Interrupteurs vidéo et captures d’écran (screenshots)
Jobs de PR : video: false ; activez la vidéo sur main ou en nocturne WebKit uniquement. Conservez screenshotOnRunFailure: true. Basculez la vidéo par spec via variable d’environnement pendant les pics, pas globalement. La vidéo est une ressource taxée sur les flottes Mac — nommez les artefacts par SHA de commit.
05 Workers parallèles et seuils de nouvelle tentative (retries)
Le parallélisme se compte en machines, pas en threads illimités : démarrez vers un job WebKit pour huit cœurs performance lorsque la vidéo est active. Réglez retries.runMode à 1 sur la branche principale WebKit, 0 sur les PR. Si plus de deux pour cent des runs relancent un test dans un sprint, corrigez les attentes plutôt que d’augmenter les seuils.
| Vérification | Paramètre | Critère d’acceptation |
|---|---|---|
| Concurrence | Machines parallèles vs cœurs | Pas de CPU soutenu > 90 % sous charge WebKit stable |
| Retries | Nombre runMode |
Propriétaire documenté et ticket lié quand un retry sauve le build |
| Artefacts | Vidéo on/off | PR : off par défaut ; main : capture sur échec uniquement |
| Timeouts | defaultCommandTimeout |
Augmentation seulement pour commandes lentes connues, pas doublée partout |
06 Validation en trois étapes avant publication
Ne livrez qu’après que ces étapes partagent le même artefact de build et le même manifeste d’environnement.
- Étape 1 : Aligner Cypress, Node et mineures macOS ; préchauffer
CYPRESS_CACHE_FOLDER. - Étape 2 : Faire correspondre vidéo, captures, workers et retries au tableau de checklist de la branche.
- Étape 3 : Exécuter les flux P0 dans Safari.app sur le même Mac — démarrage à froid et onglet en arrière-plan — et joindre la preuve au ticket.
~200 Go d’espace libre, 2 % maximum de runs relancés par sprint, rétention vidéo 7 jours sur hôtes partagés.
Accueil · Achat · Aide · Blog · Vitest vs WebKit · Playwright Safari
Louez un Mac distant pour Cypress WebKit et Safari
Enchaînez l’automatisation WebKit en mode headed et les contrôles manuels Safari sur le même hôte Apple Silicon. Consultez les parcours d’achat, les tarifs et l’aide à la mise en route sans mur de connexion, puis parcourez d’autres articles front-end sur le blog.