A lógica é a mesma da Trilha 6: automatizar os mesmos comandos que já rodam manualmente. Mas automação de navegador tem particularidades:

O alvo precisa estar de pé antes dos testes. No CI isso significa subir o site de treino (ou apontar pra um ambiente já publicado) como um passo do workflow, antes de rodar os testes, e esperar ele responder antes de seguir, não só disparar e torcer.
Instalar o navegador no runner. O ambiente de CI começa limpo; o comando de instalar o Chromium (com as dependências de sistema, não só o binário) precisa ser um passo explícito.
Tempo de execução. Testes de navegador são mais lentos que testes de API/unitários, vale medir quanto a suíte demora e decidir se roda em todo PR ou só antes de mergear.
O que fazer quando falha. Diferente de um assert de API, um teste de UI que falha se beneficia de evidência visual: trace, screenshot, vídeo no momento da falha, publicados como artefato do CI pra quem for investigar não precisar rodar local pra reproduzir.
Flakiness. Antes de confiar o merge a essa suíte, rodar ela várias vezes seguidas localmente (ou no próprio CI) pra garantir que não falha aleatoriamente: um teste de UI instável que bloqueia PRs de verdade vira motivo pra ninguém confiar nele.

No fim, a pergunta que mais importa é a mesma da Trilha 6: se a suíte reprovar o build, alguém age? Se sim, vale o investimento de deixá-la estável antes de virar portão obrigatório.

Prova do Módulo 4