← Laravel: pedidos, dados e decisões de aplicação
10 / 10 · 65 MIN

Testes, cache e diagnóstico de releases

Interpretar o alcance de testes HTTP, fakes e asserções de estado. Diagnosticar identidade e concorrência de cache, limitar invalidações e decidir aceitação com evidência do processo e da representação efetivos.

Pedidos simulados e identidade preparada

Os helpers HTTP de teste de Laravel simulam o pedido internamente; não percorrem por si a rede pública, TLS e reverse proxy. actingAs prepara o utilizador e, quando indicado, o guard do teste, sem demonstrar a verificação da password no login real.

A proteção CSRF é automaticamente desativada nos testes, pelo que um POST sem token com 200 não prova que o controlo público esteja desligado. Relaciona cada resultado com o âmbito observado antes de o usar para aceitar uma publicação.

Presença, ausência e forma exata da resposta

assertJson confirma que um fragmento existe e aceita propriedades adicionais. Um perfil com id correto pode continuar a divulgar internal_note. Usa uma asserção de ausência para o caminho proibido ou assertExactJson quando o contrato fixa a representação completa.

Não confundas sucesso HTTP com seleção correta dos campos. Um contrato extensível pode verificar campos essenciais e proibições sem fixar tudo; um contrato fechado deve tornar essa escolha explícita. Escolhe a asserção a partir do requisito, em vez de inferir mais do que ela observa.

Estado persistido e isolamento dos testes

Uma alteração recusada pode exigir duas propriedades: resposta 403 e valor original ainda presente na fatura identificada. Verificar apenas que existe alguma fatura não observa o alvo nem o montante. O estado inicial também precisa de controlo: RefreshDatabase, com esquema atualizado, executa o teste numa transação em vez de refazer sempre as migrações.

Registos confirmados por testes sem esse trait podem continuar presentes. Reconcilia a estratégia de isolamento da suite e não atribuas um resultado ao pedido sem saber que dados existiam antes dele.

O fake observa uma tentativa

Queue::fake impede a submissão real e assertPushed observa que a aplicação tentou submeter um job. Não demonstra execução de handle, configuração do worker em produção ou entrega pelo fornecedor externo. É útil verificar classe, identidade do objeto e fila esperadas, mas cada conclusão tem de corresponder à asserção usada.

A lógica do job e a integração com a fila exigem evidência distinta quando fazem parte dos critérios de aceitação. Nesta aula, os excertos são interpretados; não representam uma execução realizada pela plataforma.

Identidade da entrada e misses concorrentes

remember reutiliza um valor existente; quando falta, executa a closure e guarda o resultado. Uma chave dashboard comum a várias contas pode devolver dados da conta errada mesmo com autorização correta antes da consulta. Inclui o âmbito autorizado e as dimensões que alteram o valor na identidade da entrada.

Dois misses simultâneos podem calcular em paralelo; remember não promete exclusão distribuída. Para coordenar participantes, um lock partilhado e uma nova leitura após aquisição podem evitar recalcular trabalho já feito, desde que se respeitem duração e falhas.

Propriedade e duração do lock

Um lock tem uma identidade de proprietário e uma duração. Se um pedido o adquire e um job deve libertá-lo, passa o owner token e usa restoreLock com essa identidade. forceRelease ignora o proprietário atual e pode remover a aquisição de outro participante.

A expiração não prova que o trabalho anterior terminou: limita o trabalho à validade prevista ou define um protocolo que impeça efeitos de um executor que perdeu a exclusão. Partilhar apenas o nome em caches locais independentes também não estabelece um lock distribuído.

Invalidar e ativar com âmbito explícito

Para uma entrada conhecida, forget no store correto corresponde a uma remoção dirigida. flush não respeita o prefixo da aplicação e pode afetar outras aplicações no mesmo armazenamento. optimize:clear também remove chaves do driver de cache por omissão, além dos ficheiros gerados, pelo que não é uma limpeza exclusivamente de ficheiros.

Após publicar código e caches, os serviços de longa duração têm de carregar a revisão nova; reload ou reinício precisa de monitor que volte a arrancá-los e de observação da versão efetiva. Um comando concluído não substitui essa reconciliação.

<?php
// Separate test excerpts for interpretation; factories, policies and routes omitted.
// $otherUser is authenticated but cannot update $invoice.
$oldAmount = $invoice->amount;
$deniedResponse = $this->actingAs($otherUser)
    ->patchJson('/invoices/'.$invoice->id, ['amount' => 999]);
$deniedResponse->assertForbidden();
$this->assertDatabaseHas('invoices', [
    'id' => $invoice->id,
    'amount' => $oldAmount,
]);

// Separate successful public-profile response from another test, held in $publicResponse.
$publicResponse->assertJson(['id' => 7]);
$publicResponse->assertJsonMissingPath('internal_note');

// Dispatch evidence excerpt; this does not run the job or external delivery.
Queue::fake();
DeliverReceipt::dispatch($invoice->id);
Queue::assertPushed(DeliverReceipt::class);
NA PRÁTICA

O primeiro fragmento junta recusa HTTP e preservação do montante da fatura identificada. O fragmento seguinte pertence a outra resposta, de perfil público: verifica um campo permitido e a ausência de internal_note. O último observa uma tentativa de submissão através de fake, sem executar o job.

São exemplos separados para leitura de contratos; faltam aplicação, factories, policies e estrutura dos métodos de teste. Nenhuma avaliação exige executar estes excertos.

Armadilhas comuns

Atribuir entrega real a assertPushed; inferir ausência de dados privados a partir de assertJson parcial; tratar actingAs como teste de password; esperar limpeza total de RefreshDatabase em qualquer suite; usar chave global para valores por conta; libertar locks alheios com forceRelease.

Tópicos relacionados: Blade, saída e recursos de API · Autenticação, autorização e sessões · Filas, repetições e agendamento

Leva esta ideia contigo

A aceitação deve ligar cada requisito a uma observação do mesmo âmbito. Testes internos e fakes são úteis quando o limite fica claro. Cache exige identidade de valor e coordenação explícitas; uma publicação exige confirmar consumidores ativos, além de criar ficheiros e receber códigos de sucesso.

Criar conta

Referência: Simulated requests and CSRF · Laravel 13.x; PHP 8.3+