Testes unitários verdes não significam que pode entrar em produção
Vendemos autenticação, o que torna a nossa pergunta mais assustadora numa pergunta bem simples: quando um cliente liga a aplicação dele a nós e liga tudo, será que funciona mesmo, de ponta a ponta, no sistema real? Não "os testes unitários passam?", mas: um tenant novinho em folha consegue inscrever-se, configurar SSO e SCIM e MFA e claims personalizados e branding, apontar uma aplicação real para ele e autenticar um utilizador real com os claims certos no token, através de um navegador real? Respondemos a isso da única forma em que confiamos: com um teste de ponta a ponta que se torna num cliente.
É uma única execução do Playwright, deliberadamente sequencial e com estado, e percorre toda a vida de um tenant, do nascimento à eliminação. Um tenant inscreve-se, é configurado até aos dentes, serve um login real a uma app de consumo real, é copiado e restaurado, e depois elimina-se a si próprio. Se um único elo dessa cadeia partir, a execução fica vermelha, e não lançamos.
Configura tudo, não uma fatia do caminho feliz
O meio do teste é minucioso de propósito. Não se limita a fazer login e dar-se por satisfeito; percorre cada ecrã que um implementador real toca e exercita-o a sério: um cliente OIDC personalizado com os seus URIs de redirecionamento e definições de token, um scope personalizado que emite claims de utilizador, papéis e uma atribuição de papel, um utilizador final com um atributo personalizado, um grupo com associação real e um mapeamento de grupo para papel, ligações empresariais SAML e OIDC, um token de aprovisionamento SCIM, um domínio personalizado, uma app de aprovisionamento de saída, um colega de equipa convidado e com papel reatribuído, a faturação através de um pagamento real, o registo de auditoria com filtros e uma exportação CSV, um ambiente de testes, e as definições de segurança, de webhook e de email (cada uma comutada e depois revertida para um estado seguro). Cada um destes é criado, verificado e, onde fizer sentido, eliminado, na mesma execução.
O objetivo não é assinalar caixas. Um cliente nunca usa uma funcionalidade isolada; usa uma combinação, e é nas combinações que as coisas se partem em silêncio. Um claim personalizado só importa se aparecer no token emitido. Um mapeamento de grupo para papel só importa se o papel aterrar no exato momento em que o token é cunhado. A única forma de saber é construir tudo e depois ir usá-lo.
A dança das credenciais
Aqui está a parte que torna um teste de ponta a ponta de um produto de autenticação genuinamente desconfortável: as credenciais não existem quando o teste arranca. Não dá para fixar à força um segredo de cliente ou um token SCIM, porque o objetivo todo é que o tenant os cunhe, acabados de fazer, durante a execução.
Por isso o teste faz exatamente o que um implementador real faz, só que mais depressa. Cria o cliente OIDC no portal e relê o id do cliente e o segredo. Cunha uma credencial de Portal API num clique e captura-a. Gera um token SCIM. Depois injeta cada um desses segredos acabados de cunhar na aplicação de consumo de exemplo que está de prontidão, reescreve a configuração dessa app com os novos valores, faz o rollout, e só então conduz o login propriamente dito. Credenciais nascidas num passo são injetadas no passo seguinte na app em teste, e o navegador completa um redirecionamento OIDC real contra elas. A integração é um alvo móvel ao qual o teste continua a reapontar-se a si próprio à medida que vai tomando forma.
Essa app de consumo é uma implementação real, não um mock. Quando o teste verifica um login, uma aplicação real redirecionou mesmo para o emissor do tenant, recebeu mesmo um código de volta, trocou-o mesmo, e o teste descodifica o token resultante para confirmar que o claim personalizado e o papel mapeado estão genuinamente lá dentro. Depois conduz as arestas mais difíceis: uma página de login com marca personalizada por trás do seu interruptor de ativação, e um webhook imposto que tem de bloquear um login que a política recusa. Um teste verde neste último ponto significa que o caminho de recusa funciona, que é o resultado de que mais quer ter a certeza.
Multifator, a sério
Um login por palavra-passe prova pouco por si só. A execução regista e depois usa um autenticador TOTP e uma credencial WebAuthn através de um autenticador virtual, para que o segundo fator seja exercitado como o de um utilizador real, e não substituído por um stub.
A metade que toda a gente salta: tê-lo de volta
A maioria dos testes de ponta a ponta para em "funciona". O nosso continua para as partes em que só pensamos às 2 da manhã. Tira uma cópia de segurança, apaga os dados do tenant debaixo dos próprios pés, restaura a partir dessa cópia, e verifica que a configuração e os utilizadores voltaram intactos. Depois executa uma eliminação limpa e em autosserviço de todo o tenant. Uma execução não deixa nada para trás, que é também como sabemos que o desaprovisionamento desaprovisiona de facto.
Porque é este o teste em que confiamos
Uma parede de testes unitários verdes diz-lhe que as suas funções estão corretas. Este diz-lhe que um cliente pode entrar, construir a integração que ele de facto quer, com as funcionalidades de segurança de que ele de facto precisa, e que nós conseguimos perder os dados dele e devolvê-los. É essa a diferença entre "o código está correto" e "podemos entrar em produção".
Cada funcionalidade que esta execução exercita (SSO e SAML, SCIM, MFA, claims e scopes personalizados, branding, webhooks impostos, exportação de auditoria) está no produto em todos os níveis, e não trancada por trás de uma venda adicional empresarial. Veja o que está incluído.