Define escopo, camadas, fixtures, cenários, casos extremos, asserções e critérios de aceitação para serviços mock. Esta referência fixa o limite de adoção, comportamento em falhas e evidências observáveis, deixando os limites específicos do ambiente configuráveis.
Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não se afirma que uma implementação adotante os tenha aprovado.
Decisão
Para serviços mock, adote um plano de teste baseado em risco e versionado com fixtures reproduzíveis e gates próprios. Trate o bloco como um contrato de lançamento e regressão construído a partir de casos representativos positivos, de limite, negação, falha e recuperação. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais a partir de evidências em seu próprio ambiente.
Escopo
- Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente dos serviços mock descritos por este bloco de teste.
- Interfaces primárias e alternativas, trabalho em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercitar o mesmo limite.
- Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.
Fora deste bloco
- Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
- Afirmar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.
Contrato
- Trace cada teste crítico a um comportamento, limite, incidente ou risco e afirme resultados visíveis externamente ou evidências duráveis.
- Controle relógio, aleatoriedade, identidade, rede e dependências de dados para que reexecuções distingam defeitos do produto de instabilidade da fixture.
- Mantenha dados sensíveis de produção e credenciais fora das fixtures; gere casos sintéticos representativos de limite e abuso.
- Defina critérios de retry, quarentena, propriedade, expiração e remoção para testes instáveis; retries não podem transformar uma falha em sucesso silencioso.
- Registre versão da fixture, ambiente, configuração, resultado observado e localização da evidência para cada execução decisória.
- Separe falha do produto, falha de dependência, falha da infraestrutura de teste e evidência inconclusiva nos relatórios.
- Gere comportamento mock a partir do contrato de produção versionado, incluindo autenticação, transições de estado, validação, paginação, erros, temporização, retries, limites de taxa e idempotência.
- Torne fixtures determinísticas e modos de falha explícitos, impeça que credenciais ou dados de produção entrem nos mocks e execute verificações de contrato que revelem deriva em vez de ensinar comportamento falso aos clientes.
Orientações de implementação
- Construa o menor conjunto determinístico de fixtures que cubra classes de risco, depois adicione casos derivados da produção somente após revisão segura de privacidade.
- Modele entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências dos serviços mock antes de selecionar detalhes de framework ou fornecedor.
- Armazene a versão aplicável do contrato ou política dos serviços mock com estado material para que migrações, replay e decisões de suporte permaneçam atribuíveis.
- Introduza o caminho por trás da implantação controlada, compare resultados esperados e observados e mantenha uma rota de recuperação testada até que a evidência de adoção esteja completa.
Tratamento de falhas e salvaguardas
- Um ambiente de teste quebrado reporta um resultado de infraestrutura distinto da falha do produto e não pode satisfazer um gate de liberação obrigatório.
- Estado inválido ou contraditório dos serviços mock é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique um efeito.
- Retries são limitados e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.
Verificação e operações
- Execute a suíte duas vezes a partir de um estado limpo e confirme que ordenação, retries e execução paralela não alteram o veredito.
- Monitore sucesso, negação, falha de validação, falha de dependência, esgotamento de retry e recuperação dos serviços mock por versão de contrato sem dimensões sensíveis do payload.
- Reexecute fixtures positivas e negativas emparelhadas após mudanças de política, esquema, dependência, migração ou limite e preserve a evidência resultante.
Premissas de adoção
- Nomes e valores no exemplo são uma fixture concreta, não padrões universais; adotantes os substituem por meio de evidência documentada e propriedade.
- O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudança.
Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório alvo antes de registrar evidências da implementação.