Como o exemplo de encaminhamento de contatos se comporta nos testes

O que este exemplo realmente fez?

Conferimos cinco caminhos definidos no fluxo fictício de atendimento da Northstar Plumbing em 8 de outubro de 2026. Cada caminho foi executado com as regras de atendimento do repositório e, separadamente, com o pacote do kit inicial para download. A tabela registra esses resultados finitos; não é um estudo de caso de cliente nem um índice de confiabilidade em produção.

As entradas e as expectativas foram definidas antes.

O dado de teste completo é Alex Morgan, em alex@example.com, Bristol BS1, perguntando sobre uma torneira de cozinha que está pingando há uma semana. O dado de teste incompleto é Sam Taylor, em sam@example.com, sem área e com a mensagem “Can you help?” (Pode me ajudar?). São contatos fictícios.

O caso de duplicado reenvia o pedido de Alex com outro nome de exibição, texto em maiúsculas e espaços extras. A aprovação repetida tenta substituir uma resposta já aprovada. O caso de recuperação usa o sinalizador explícito de falha simulada, tenta pular a restauração, restaura o mesmo registro e depois o aprova de novo.

Rode e compare com o seu próprio resultado.

Baixe o kit inicial 1.0.0, extraia e siga o README. As verificações incluídas contêm os estados e as asserções esperados. Rode node verify.mjs para gerar um relatório novo com as entradas, as expectativas e o histórico observado dos cinco casos. Se um caso falhar, o comando termina sem sucesso.

A execução do código-fonte do repositório chamou diretamente os auxiliares atuais em TypeScript. A execução do kit inicial carregou o JavaScript empacotado sem importar arquivos do repositório. As definições de teste compartilhadas tornam a comparação reproduzível; as duas execuções não são provas independentes de que todas as regras possíveis estão corretas.

O pacote também tem um ensaio de pausa separado.

A camada de linha de comando do pacote acrescenta armazenamento em arquivo local e controles de pausa e retomada. O ensaio de onze comandos inicializou um registro, simulou uma falha, pausou, tentou uma restauração bloqueada, retomou, restaurou, aprovou duas vezes e reiniciou. A restauração durante a pausa terminou com erro de propósito e deixou o estado inalterado. Retomar não repetiu nenhuma ação.

Essa é uma verificação negativa bem-sucedida, não um teste com falha omitido. node cli-check.mjs roda a sequência em uma pasta temporária e remove essa pasta no final. Esses recursos de linha de comando não existem na demonstração no navegador.

O que continua sem comprovação

A memória de duplicados do navegador some ao reiniciar, recarregar a página ou trocar de fluxo. O kit inicial grava um arquivo local, mas não tem trava para vários usuários nem um armazenamento de registros de produção. Uma mensagem alterada pode ser um novo contato; esta chave não consegue decidir se dois pedidos escritos de forma diferente descrevem o mesmo serviço.

Uma implementação real precisaria de identificadores permanentes de pedidos e de ações, de uma decisão sobre pedidos alterados e de verificações do destino antes de tentar de novo. São acréscimos necessários, não correções demonstradas por estes resultados locais. A falha simulada não envia nada, então não testa uma conexão que agiu com sucesso e depois perdeu a confirmação.

Destes cinco casos não decorre nenhuma economia de trabalho para clientes, taxa de conversão, integração ao vivo, disponibilidade ou entrega exatamente uma vez. A suíte de testes unitários existente no repositório passou, separadamente, em 21 verificações do auxiliar de atendimento. Essa suíte mais ampla é uma cobertura de regressão útil, não 21 testes com clientes nem 21 sessões no navegador.