Modo Navegador (experimental)

Esta página fornece informações sobre o recurso experimental de modo navegador na API Vitest, que permite executar seus testes nativamente no navegador, fornecendo acesso a variáveis globais do navegador, como window e document. Este recurso está em desenvolvimento e as APIs podem mudar no futuro.

Motivação

Desenvolvemos o recurso de modo navegador do Vitest para aprimorar os fluxos de trabalho de teste e obter resultados mais precisos e confiáveis. Esta adição experimental à nossa API de teste permite que desenvolvedores executem testes em um ambiente de navegador nativo. Nesta seção, exploraremos as motivações por trás desse recurso e seus benefícios para testes.

Diferentes maneiras de testar

Existem várias maneiras de testar código JavaScript. Algumas estruturas de teste simulam ambientes de navegador no Node.js, enquanto outras executam testes em navegadores reais. Neste contexto, jsdom é um exemplo de implementação de especificação que simula um ambiente de navegador, sendo usado com um executor de teste como Jest ou Vitest. Outras ferramentas de teste, como WebdriverIO ou Cypress, permitem que desenvolvedores testem seus aplicativos em um navegador real ou, no caso do Playwright, fornecem um mecanismo de controle de navegador.

A ressalva da simulação

Testar programas JavaScript em ambientes simulados, como jsdom ou happy-dom, simplificou a configuração dos testes e forneceu uma API fácil de usar, tornando-os adequados para muitos projetos e aumentando a confiança nos resultados do teste. No entanto, é crucial ter em mente que essas ferramentas apenas simulam um ambiente de navegador, e não um navegador real, o que pode resultar em discrepâncias entre o ambiente simulado e o ambiente real. Portanto, falsos positivos ou negativos nos resultados do teste podem ocorrer.

Para alcançar o mais alto nível de confiança em nossos testes, é crucial testar em um ambiente de navegador real. É por isso que desenvolvemos o recurso de modo navegador no Vitest, permitindo que desenvolvedores executem testes nativamente em um navegador e obtenham resultados de teste mais precisos e confiáveis. Com o teste em nível de navegador, desenvolvedores podem ter mais confiança de que seu aplicativo funcionará como pretendido em um cenário do mundo real.

Desvantagens

Ao usar o navegador Vitest, é importante considerar as seguintes desvantagens:

Desenvolvimento Inicial

O recurso de modo navegador do Vitest ainda está em estágios iniciais de desenvolvimento. Como tal, pode não estar totalmente otimizado e pode haver bugs ou problemas que ainda não foram resolvidos. Recomenda-se complementar o uso do navegador Vitest com um executor de testes independente no navegador, como WebdriverIO, Cypress ou Playwright.

Inicialização Mais Demorada

O navegador Vitest requer a inicialização do provedor e do navegador durante o processo de configuração, o que pode levar algum tempo. Isso pode resultar em tempos de inicialização mais longos em comparação com outros padrões de teste.

Configuração

Para ativar o modo navegador na sua configuração do Vitest, você pode usar a flag --browser ou definir o campo browser.enabled como true no seu arquivo de configuração do Vitest. Aqui está um exemplo de configuração usando o campo do navegador:

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      name: 'chrome', // browser name is required
    },
  },
});

Tipos de Opções do Navegador:

A opção de navegador no Vitest depende do provedor. O Vitest retornará um erro se você passar --browser e não especificar seu nome no arquivo de configuração. Opções disponíveis:

• webdriverio (padrão) suporta estes navegadores:
  • firefox
  • chrome
  • edge
  • safari
• playwright suporta estes navegadores:
  • firefox
  • webkit
  • chromium

Testes Multiplataforma:

Quando você especifica um nome de navegador na opção de navegador, o Vitest tentará executar o navegador especificado usando WebdriverIO por padrão e, em seguida, executar os testes lá. Este recurso torna o teste entre navegadores fácil de usar e configurar em ambientes como um CI. Se você não quiser usar o WebdriverIO, você pode configurar o provedor de navegador personalizado usando a opção browser.provider.

Para especificar um navegador usando a CLI, use a flag --browser seguido pelo nome do navegador, assim:

npx vitest --browser=chrome

Ou você pode fornecer opções de navegador para a CLI com notação de ponto:

npx vitest --browser.name=chrome --browser.headless

NOTE

Ao usar a opção de navegador Safari com WebdriverIO, o safaridriver precisa ser ativado executando sudo safaridriver --enable no seu dispositivo.

Além disso, ao executar seus testes, o Vitest tentará instalar alguns drivers para compatibilidade com safaridriver.

Headless

O modo headless é outra opção disponível no modo navegador. No modo headless, o navegador é executado em segundo plano sem uma interface de usuário, o que o torna útil para executar testes automatizados. A opção headless no Vitest pode ser definida como um valor booleano para ativar ou desativar o modo headless.

Aqui está um exemplo de configuração habilitando o modo headless:

export default defineConfig({
  test: {
    browser: {
      enabled: true,
      headless: true,
    },
  },
});

Você também pode definir o modo headless usando a flag --browser.headless na CLI, assim:

npx vitest --browser.name=chrome --browser.headless

Neste caso, o Vitest será executado no modo headless usando o navegador Chrome.

Limitações

Diálogos de Bloqueio de Thread

Ao usar o Vitest Browser, é importante observar que diálogos de bloqueio de thread como alert ou confirm não podem ser usados nativamente. Isso ocorre porque eles bloqueiam a página da web, o que significa que o Vitest não pode continuar se comunicando com a página, fazendo com que a execução trave.

Em tais situações, o Vitest fornece mocks padrão com valores retornados padrão para essas APIs. Isso garante que, se o usuário acidentalmente usar APIs da web de popup síncronas, a execução não seja interrompida. No entanto, ainda é recomendado que o usuário faça mock dessas APIs web para uma melhor experiência. Leia mais em Mocking.