Escrever o teste em cima de .btn-azul-grande funciona no curto prazo, mas é uma dívida: qualquer redesign (cor, tamanho, biblioteca de UI) quebra o teste sem o comportamento ter mudado nada. A conduta:

Conversar com quem desenvolve antes de escrever o teste: pedir pra adicionar um data-testid estável no botão (e nos outros elementos do fluxo) é geralmente uma mudança de uma linha.
Explicar o motivo em termos de custo, não de preferência pessoal: cada vez que o design mexe, alguém vai ter que consertar o teste, e isso tende a acontecer bem mais vezes que uma mudança real de comportamento no login.
Se não der pra mudar agora (código de terceiro, prioridade do time), usar o seletor mais estável disponível (texto visível do botão, papel de acessibilidade, role=button) e documentar no próprio teste que é um seletor provisório, não o ideal.
Propor a convenção pra frente: um padrão de data-testid combinado com o time facilita qualquer automação futura, não só a sua.

No fim, seletor de teste é também uma decisão de arquitetura do produto: vale a conversa, não só o contorno técnico.

Prova do Módulo 1