Novidades do Cypress 16

O Cypress 16 executa o Chrome, o Chromium e o Edge sobre a pilha de rede nativa do navegador, com HTTP/2. Ele também digita e verifica a visibilidade mais rápido por padrão, além de remover Cypress.env() e cy.exec(). Atualize para a versão 16.1.0 ou posterior, não para a 16.0.0.

Atualizações de versão principal costumam quebrar no CI, não localmente. Uma API removida lança um erro dentro de um arquivo de suporte, ou uma execução para de exibir saída até o job estourar o tempo limite.

Este artigo aborda o Cypress 16.0.0 (1º de setembro de 2026) e o 16.1.0 (15 de setembro de 2026): o que fica mais rápido, o que muda na forma de escrever testes, o que quebra e como corrigir, e qual versão fixar. Para os fundamentos, veja testes end-to-end com Cypress.

HTTP/2 é o padrão no Chrome, no Chromium e no Edge

No Cypress 16, o Chrome, o Chromium e o Edge passam a interceptar o tráfego dos testes na própria pilha de rede do navegador, em vez de encaminhá-lo pelo proxy do Cypress. A aplicação sob teste se conecta diretamente ao seu servidor e usa o melhor protocolo suportado pelos dois lados, incluindo HTTP/2 ou HTTP/3. O Firefox, o WebKit e o Electron mantêm o caminho legado via HTTP/1.1.

A mudança para o HTTP/2 nativo é importante porque o HTTP/1.1 permite apenas algumas conexões paralelas por origem, então uma página com centenas de recursos precisa enfileirá-los. O HTTP/2 multiplexa todas essas requisições como streams sobre uma única conexão. No benchmark do próprio Cypress, uma página que carrega 1.000 imagens caiu de 3.896 ms com HTTP/1.1 para 1.362 ms com HTTP/2. O anúncio não descreve o ambiente de teste, então encare esse número como uma tendência, e não como uma previsão para a sua suíte.

O HTTP/2 nativo também torna testáveis no Cypress 16 as interfaces baseadas em streaming. Com HTTP/1.1, o navegador permite apenas seis conexões de Server-Sent Events por domínio, o que deixava recursos como notificações em tempo real fora de alcance. Com HTTP/2, o servidor e o navegador negociam quantos streams podem ser executados simultaneamente, e o Cypress indica 100 como o padrão usual.

O Cypress 16 também deixa de fazer a terminação TLS para a aplicação sob teste, então o navegador verifica o certificado real da sua origem. Para certificados de desenvolvimento autoassinados ou uma CA interna, a 16.1.0 adiciona trustedCertificates.

Mudanças de velocidade dos testes no Cypress 16

O Cypress 16 altera três padrões que afetam a velocidade. Cada um deles pode ser revertido.

• O atraso entre teclas é de 0 ms, em vez de 10 ms. Para campos que dependem do ritmo de digitação, como campos de busca com debounce, você pode restaurar o atraso anterior:

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

Na 16.0.0, definir keystrokeDelay em um arquivo de configuração TypeScript gerava erro de compilação. A 16.1.0 corrige isso.

• As verificações de visibilidade usam o algoritmo moderno. Ele é baseado no método nativo do navegador Element.checkVisibility(), e visibilityStrategy tem 'modern' como padrão.
• manageBrowserMemory vem ativado por padrão. Durante a execução dos testes, o Cypress verifica o uso de memória periodicamente. Se uma leitura ultrapassar um limite definido, ele executa a coleta de lixo antes do início do próximo teste. Essa limpeza consome tempo, então uma suíte leve pode ficar mais rápida com a opção desativada. Meça o tempo da sua suíte das duas formas antes de desativá-la.

O que muda na forma de escrever testes no Cypress 16?

No Cypress 16, as leituras de cookies e de storage passam a fazer retentativas como as outras queries, e o acesso a variáveis de ambiente é dividido em duas APIs distintas.

cy.getCookie(), cy.getCookies(), cy.getAllCookies(), cy.getAllLocalStorage() e cy.getAllSessionStorage() agora são comandos de query com retentativa, regidos por defaultCommandTimeout. Eles não usam mais responseTimeout, embora cy.setCookie() continue usando. Encadeie um .should() e o comando continuará tentando até a asserção passar. Se a verificação ficar dentro de um .then(), ela é executada uma única vez, sem retentativa.

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

Se a sua suíte sobrescreve algum desses comandos, passe a usar Cypress.Commands.overwriteQuery(). Cypress.Commands.overwrite() não funciona mais com eles.

Cypress.env() foi descontinuado na 15.10.0 e agora foi removido. cy.env() é assíncrono: ele obtém valores sensíveis do processo Node e entrega ao teste apenas as chaves que você especificar. Cypress.expose() é a opção síncrona para valores que podem ser exibidos com segurança no navegador.

// 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() registra os nomes das chaves no Command Log, mas nunca os valores. Essa proteção termina assim que o objeto é entregue a você: .its(), .invoke(), asserções ou um comando com falha podem exibir um valor, então mantenha os segredos dentro do .then(). As sobrescritas por teste e por suíte agora recebem expose: {...} em vez de env: {...}, e allowCypressEnv foi removido.

Breaking changes do Cypress 16 e como corrigi-las

A maioria das quebras do Cypress 16 são remoções mecânicas, e o guia de migração traz um substituto direto para cada uma. A que exige mais atenção é o cy.intercept().

A API do cy.intercept() em si não mudou. Na rede nativa, porém, req.httpVersion não é informado, cabeçalhos de compressão como content-encoding não aparecem porque o corpo já chega decodificado, respostas revalidadas retornam 200 em vez de 304 e res.statusMessage fica vazio com HTTP/2 e HTTP/3. Além disso, responseTimeout não limita mais os handlers de resposta. Se nenhuma resposta chegar, o Cypress desiste após 30 segundos fixos e, se você precisar de um limite diferente, deve defini-lo no cy.wait(). Ajuste as asserções para que verifiquem o comportamento, e não detalhes de transporte. Os padrões descritos em mocking e stubbing no Cypress continuam válidos.

// 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)

A lista completa de breaking changes da 16.0.0, com o que acontece se cada uma não for tratada:

No caso do viewport, mova a configuração para o bloco:

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

As saídas de emergência do Cypress 16 são temporárias

O Cypress 16 inclui duas opções de desativação, e o changelog marca ambas como descontinuadas. forceHttp1: true faz todos os navegadores voltarem ao caminho legado via proxy. O Cypress a marcou como descontinuada na mesma versão em que a adicionou e planeja removê-la quando o caminho nativo tiver suporte de longo prazo tanto no Chrome quanto no Firefox. visibilityStrategy: 'legacy' restaura o algoritmo de visibilidade antigo. A própria opção está descontinuada, e o changelog recomenda tratar o valor legado como uma solução provisória enquanto você migra.

Use forceHttp1 e visibilityStrategy: 'legacy' para diagnosticar falhas, não como configurações permanentes. Se uma falha desaparecer com a flag ativada, compare-a com as diferenças documentadas da rede nativa, reescreva a asserção e depois remova a flag.

Veredito: atualize para o Cypress 16.1.0 ou posterior, não para o 16.0.0

Atualize e fixe a versão 16.1.0 ou uma versão 16.x mais recente, nunca a 16.0.0. A 16.1.0 corrige uma regressão da 16.0.0 em que execuções no Chrome, no Chromium e no Edge podiam ficar sem saída no meio do caminho e nunca terminar. Ela também corrige o problema de blockHosts não ser aplicado nesses navegadores: requisições para um host bloqueado eram enviadas à rede quando deveriam falhar com um 503. Uma suíte que depende de hosts bloqueados podia passar na 16.0.0 sem de fato testar o que se propõe a testar. A 16.1.0 também corrige o erro de TypeScript com keystrokeDelay e um vazamento de memória em service workers.

Faça o seu primeiro build verde na versão 16 no Chrome, e não apenas no Electron. O Electron continua no caminho legado, então uma execução exclusiva no Electron nunca passa pela rede nativa. Depois disso, confira a sua suíte em relação às boas práticas do Cypress. Suas execuções no Firefox e no WebKit continuam usando HTTP/1.1, enquanto os usuários reais do Firefox e do Safari usam HTTP/2 em produção. Por isso, o session replay de usuários reais é uma forma útil de encontrar os fluxos e navegadores que a sua suíte E2E nunca exercita.

Conclusão

A maior parte do que o Cypress 16 acelera não exige nenhum trabalho da sua parte. A maior parte do que ele quebra pode ser encontrada com uma busca no seu repositório. Procure por Cypress.env, cy.exec, cy.end, chamadas a Cypress.config() em tempo de execução e as chaves experimentais removidas. Substitua cada ocorrência usando a tabela acima, migre o CI para o Node 22 ou posterior com o Chrome e instale diretamente a versão 16.1.0 ou posterior.

Perguntas frequentes

Como executar um comando de shell no Cypress 16, já que o cy.exec() foi removido?

Registre uma task em setupNodeEvents que use o módulo child_process do Node, por exemplo execFileSync, e chame-a no teste com cy.task('resetDatabase'). Toda task precisa retornar um valor ou null. Por padrão, uma task desiste após 60 segundos, e taskTimeout altera esse limite. O cy.task() não consegue executar processos que nunca terminam, como a inicialização de um servidor. O cy.exec() foi descontinuado no Cypress 15.21.0 e removido na 16.0.0.

Qual é a diferença entre trustedCertificates e clientCertificates no Cypress?

trustedCertificates, adicionado no Cypress 16.1.0, faz o navegador confiar em um certificado apresentado pelo seu servidor, como um certificado de desenvolvimento autoassinado ou emitido por uma CA interna. clientCertificates serve para TLS mútuo, em que o Cypress apresenta um certificado ao servidor. Cada entrada de trustedCertificates aceita exatamente um entre filePath, pem ou spki, e se aplica ao caminho de rede nativo no Chrome, no Chromium e no Edge. As origens declaradas podem então usar o cache HTTP do navegador.

Posso executar testes de componentes do Angular 20 no Cypress 16?

Não com o harness integrado. Os testes de componentes do Cypress 16 não oferecem mais suporte ao Angular 18, 19 ou 20, e a versão mínima suportada é o Angular 21.0.0. Como solução provisória, você pode instalar pelo npm o pacote descontinuado @cypress/angular 4.x e importar o mount dele em vez de cypress/angular, mas o Cypress não oferece mais suporte a esse harness, então planeje a migração para o Angular 21. A mesma versão também remove o suporte integrado ao CoffeeScript, de modo que specs, arquivos de suporte e fixtures .coffee não são mais resolvidos.