Les nouveautés de Cypress 16

Cypress 16 exécute Chrome, Chromium et Edge sur la pile réseau native du navigateur, avec HTTP/2. Par défaut, il saisit le texte et vérifie la visibilité plus rapidement. Il supprime aussi Cypress.env() et cy.exec(). Passez à la version 16.1.0 ou ultérieure, pas à la 16.0.0.

Les mises à niveau majeures cassent généralement en CI, pas en local. Une API supprimée lève une erreur dans un fichier de support, ou une exécution cesse d’afficher sa sortie jusqu’à ce que le job expire.

Cet article couvre Cypress 16.0.0 (1er septembre 2026) et 16.1.0 (15 septembre 2026). Il présente ce qui devient plus rapide, ce qui change dans l’écriture de vos tests, ce qui casse et comment le corriger, ainsi que la version à épingler. Pour les fondamentaux, consultez les tests end-to-end avec Cypress.

HTTP/2 par défaut dans Chrome, Chromium et Edge

Avec Cypress 16, Chrome, Chromium et Edge interceptent désormais le trafic des tests sur la pile réseau propre au navigateur, au lieu de le faire transiter par le proxy Cypress. L’application testée se connecte directement à votre serveur et utilise le meilleur protocole pris en charge des deux côtés, y compris HTTP/2 ou HTTP/3. Firefox, WebKit et Electron conservent l’ancien chemin HTTP/1.1.

Ce passage au HTTP/2 natif est important. HTTP/1.1 n’autorise que quelques connexions parallèles par origine : une page comportant des centaines de ressources doit donc les mettre en file d’attente. HTTP/2 multiplexe toutes ces requêtes sous forme de flux sur une seule connexion. Dans le benchmark de Cypress, le chargement d’une page de 1 000 images passe de 3 896 ms en HTTP/1.1 à 1 362 ms en HTTP/2. L’annonce ne décrit pas les conditions du test : considérez ce chiffre comme une tendance plutôt que comme une prévision pour votre suite.

Le HTTP/2 natif rend aussi les interfaces de streaming testables dans Cypress 16. En HTTP/1.1, un navigateur n’autorise que six connexions Server-Sent Events par domaine, ce qui rendait inaccessibles des fonctionnalités comme les notifications en temps réel. En HTTP/2, le serveur et le navigateur négocient le nombre de flux simultanés, et Cypress indique une valeur par défaut habituelle de 100.

Cypress 16 ne termine plus non plus le TLS pour l’application testée : le navigateur vérifie donc le véritable certificat de votre origine. Pour les certificats de développement auto-signés ou une autorité de certification interne, la version 16.1.0 ajoute trustedCertificates.

Les changements de vitesse des tests dans Cypress 16

Cypress 16 modifie trois valeurs par défaut qui influent sur la vitesse. Chacune peut être rétablie.

• Le délai entre frappes passe à 0 ms, contre 10 ms auparavant. Pour les champs sensibles au rythme de saisie, comme les champs de recherche avec debounce, vous pouvez rétablir l’ancien délai :

Cypress.Keyboard.defaults({ keystrokeDelay: 10 })
cy.get('[data-cy=search]').type('laptop', { delay: 10 })

En 16.0.0, placer keystrokeDelay dans un fichier de configuration TypeScript provoquait une erreur de compilation. La version 16.1.0 corrige ce problème.

• Les vérifications de visibilité utilisent le nouvel algorithme. Il s’appuie sur la méthode native du navigateur Element.checkVisibility(), et visibilityStrategy vaut 'modern' par défaut.
• manageBrowserMemory est activé par défaut. Pendant l’exécution des tests, Cypress contrôle l’utilisation de la mémoire à intervalles réguliers. Si une mesure dépasse un seuil défini, il lance le ramasse-miettes avant le test suivant. Ce nettoyage prend du temps : une suite légère peut donc être plus rapide avec ce paramètre désactivé. Chronométrez votre suite dans les deux configurations avant de le désactiver.

Qu’est-ce qui change dans l’écriture des tests avec Cypress 16 ?

Dans Cypress 16, les lectures de cookies et de stockage font l’objet de nouvelles tentatives comme les autres requêtes. L’accès à l’environnement est par ailleurs réparti entre deux API distinctes.

cy.getCookie(), cy.getCookies(), cy.getAllCookies(), cy.getAllLocalStorage() et cy.getAllSessionStorage() sont désormais des commandes de requête avec nouvelles tentatives, régies par defaultCommandTimeout. Elles n’utilisent plus responseTimeout, contrairement à cy.setCookie(), qui l’utilise toujours. Si vous chaînez un .should(), la commande réessaie jusqu’à ce que l’assertion passe. Si vous placez la vérification dans un .then(), elle s’exécute une seule fois, sans nouvelle tentative.

cy.getCookie('auth_token').should('have.property', 'value')

Si votre suite surcharge l’une de ces commandes, passez à Cypress.Commands.overwriteQuery(). Cypress.Commands.overwrite() ne fonctionne plus sur elles.

Cypress.env(), déprécié depuis la version 15.10.0, est désormais supprimé. cy.env() est asynchrone : il récupère les valeurs sensibles depuis le processus Node et ne transmet à votre test que les clés que vous nommez. Cypress.expose() est l’option synchrone, réservée aux valeurs qui peuvent être affichées sans risque dans le navigateur.

// Before (Cypress 15)
const token = Cypress.env('STRIPE_KEY')

// After (Cypress 16)
cy.env(['STRIPE_KEY']).then(({ STRIPE_KEY }) => {
  cy.request({ url: '/api/charge', headers: { Authorization: STRIPE_KEY } })
})
const apiBase = Cypress.expose('PUBLIC_API_URL')

cy.env() inscrit le nom des clés dans le Command Log, mais jamais leurs valeurs. Cette protection cesse dès qu’il vous remet l’objet : .its(), .invoke(), les assertions ou une commande en échec peuvent tous afficher une valeur. Gardez donc vos secrets à l’intérieur du .then(). Les surcharges au niveau d’un test ou d’une suite acceptent désormais expose: {...} au lieu de env: {...}, et allowCypressEnv a été supprimé.

Changements cassants de Cypress 16 et corrections

La plupart des changements cassants de Cypress 16 sont de simples suppressions, et le guide de migration propose un remplacement direct pour chacune. Le seul qui demande réflexion concerne cy.intercept().

L’API de cy.intercept() elle-même ne change pas. Sur le réseau natif, en revanche, plusieurs comportements diffèrent :

• req.httpVersion n’est pas renseigné.
• Les en-têtes de compression comme content-encoding sont absents, car le corps arrive déjà décodé.
• Les réponses revalidées renvoient 200 au lieu de 304.
• res.statusMessage est vide en HTTP/2 et HTTP/3.

responseTimeout ne limite plus non plus les gestionnaires de réponse. Si aucune réponse n’arrive, Cypress abandonne au bout d’un délai fixe de 30 secondes. Pour une autre limite, définissez-la sur cy.wait(). Modifiez vos assertions pour qu’elles ciblent le comportement plutôt que les détails du transport. Les patterns présentés dans le mocking et le stubbing avec Cypress restent valables.

// Before: expect(req.httpVersion).to.eq('1.1')
cy.intercept('GET', '/api/cart').as('cart')
cy.visit('/checkout')
cy.wait('@cart', { timeout: 15000 }).its('response.statusCode').should('eq', 200)

Voici la liste complète des changements cassants de la version 16.0.0, avec les conséquences si vous ne les corrigez pas :

Pour le viewport, déplacez le paramètre dans la configuration du bloc :

describe('mobile nav', { viewportWidth: 375, viewportHeight: 667 }, () => {
  it('opens the menu', () => { /* ... */ })
})

Les solutions de repli de Cypress 16 sont temporaires

Cypress 16 propose deux options de désactivation, et le changelog les marque toutes deux comme dépréciées.

• forceHttp1: true renvoie tous les navigateurs vers l’ancien chemin via le proxy. Cypress l’a marquée comme dépréciée dans la version même qui l’a introduite. L’éditeur prévoit de la supprimer dès que le chemin natif bénéficiera d’un support à long terme dans Chrome et Firefox.
• visibilityStrategy: 'legacy' rétablit l’ancien algorithme de visibilité. L’option elle-même est dépréciée, et le changelog recommande de considérer la valeur legacy comme une solution provisoire le temps de la migration.

Utilisez forceHttp1 et visibilityStrategy: 'legacy' pour diagnostiquer des échecs, pas comme réglages permanents. Si un échec disparaît avec l’option activée, comparez-le aux différences documentées du réseau natif, réécrivez l’assertion, puis retirez l’option.

Verdict : passez à Cypress 16.1.0 ou ultérieur, pas à la 16.0.0

Faites la mise à niveau et épinglez la version 16.1.0 ou une version 16.x plus récente, jamais la 16.0.0. La 16.1.0 corrige plusieurs problèmes de la 16.0.0 :

• Exécutions bloquées : dans Chrome, Chromium et Edge, une exécution pouvait devenir muette en cours de route et ne jamais se terminer.
• blockHosts non appliqué : dans ces mêmes navigateurs, les requêtes vers un hôte bloqué partaient sur le réseau alors qu’elles auraient dû échouer avec une erreur 503. Une suite qui dépend des hôtes bloqués pouvait donc passer en 16.0.0 sans réellement tester ce qu’elle prétend tester.
• Autres correctifs : l’erreur TypeScript liée à keystrokeDelay et une fuite mémoire liée aux service workers.

Exécutez votre premier build réussi en version 16 dans Chrome, pas seulement dans Electron. Electron reste sur l’ancien chemin : une exécution limitée à Electron ne sollicite donc jamais le réseau natif. Ensuite, confrontez votre suite aux bonnes pratiques de test avec Cypress. Vos exécutions Firefox et WebKit utilisent toujours HTTP/1.1, alors que les vrais utilisateurs de Firefox et Safari bénéficient de HTTP/2 en production. Le session replay des utilisateurs réels est donc un bon moyen d’identifier les parcours et les navigateurs que votre suite E2E ne couvre jamais.

Conclusion

La plupart des gains de vitesse de Cypress 16 ne vous demandent aucun travail. La plupart de ce qu’il casse se repère par une simple recherche dans votre dépôt. Recherchez Cypress.env, cy.exec, cy.end, les appels à Cypress.config() à l’exécution et les clés expérimentales supprimées. Remplacez chaque occurrence à l’aide du tableau ci-dessus, passez la CI sur Node 22 ou ultérieur avec Chrome, et installez directement la version 16.1.0 ou ultérieure.

FAQ

Comment exécuter une commande shell dans Cypress 16 maintenant que cy.exec() est supprimé ?

Enregistrez une tâche dans setupNodeEvents qui appelle le module child_process de Node, par exemple execFileSync, puis appelez-la depuis le test avec cy.task('resetDatabase'). Chaque tâche doit renvoyer une valeur ou null. Par défaut, une tâche abandonne au bout de 60 secondes ; taskTimeout permet de modifier cette limite. cy.task() ne peut pas exécuter des processus qui ne se terminent jamais, comme le démarrage d'un serveur. cy.exec() a été déprécié dans Cypress 15.21.0 et supprimé dans la version 16.0.0.

Quelle est la différence entre trustedCertificates et clientCertificates dans Cypress ?

trustedCertificates, ajouté dans Cypress 16.1.0, permet au navigateur de faire confiance à un certificat présenté par votre serveur, comme un certificat de développement auto-signé ou émis par une autorité de certification interne. clientCertificates sert au TLS mutuel, où c'est Cypress qui présente un certificat au serveur. Chaque entrée de trustedCertificates accepte exactement une seule des propriétés filePath, pem ou spki, et s'applique au chemin réseau natif dans Chrome, Chromium et Edge. Les origines déclarées peuvent alors utiliser le cache HTTP du navigateur.

Puis-je exécuter des tests de composants Angular 20 avec Cypress 16 ?

Pas avec le harnais intégré. Les tests de composants de Cypress 16 ne prennent plus en charge Angular 18, 19 ou 20 : la version minimale prise en charge est Angular 21.0.0. En solution provisoire, vous pouvez installer depuis npm le package déprécié @cypress/angular 4.x et y importer mount au lieu de cypress/angular. Cypress ne prend toutefois plus en charge ce harnais : prévoyez donc la migration vers Angular 21. Cette même version supprime aussi la prise en charge intégrée de CoffeeScript, si bien que les specs, fichiers de support et fixtures en .coffee ne sont plus résolus.