Teste seu pipeline de odds da Pinnacle offline antes do lançamento

Um pipeline de polling da API de odds da Pinnacle pode ser testado quase inteiramente offline. Capture um pequeno conjunto de respostas reais enquanto estiver na chave gratuita, depois reproduza esses arquivos pelo seu parser, pela sua lógica de cursor e pela sua camada de armazenamento. Só frescor e temporização ainda precisam da API ao vivo. Todo o resto pode falhar com segurança na sua máquina primeiro.

Grave um conjunto de fixtures uma vez

Você precisa de três gravações: uma leitura completa do board, a leitura delta que a segue e uma resposta de erro. A API REST responde a uma leitura completa com um array de eventos e um cursor last; envie esse cursor de volta como since e a próxima chamada retorna apenas o que mudou. O contraste documentado é nítido: 1.522 eventos para um board completo de futebol pré-jogo contra 7 eventos alterados no delta seguinte, como o guia de integração nota, verificado em 2026-09-29.

Salve cada corpo de resposta em um arquivo com seu código de status, seus cabeçalhos e o cursor que você passou. A cota da chave gratuita, 100 requisições por dia, cobre isso e deixa o dia quase intacto. Mantenha os arquivos no seu repositório ao lado dos testes e atualize-os quando mudar os esportes que cobre.

Reproduza pelo seu parser

Aponte o parser para os arquivos em vez da rede. Ele deve produzir o mesmo estado de mercado a partir da leitura completa gravada todas as vezes, e aplicar o delta gravado deve mudar exatamente os eventos que mudaram. É aqui que a maioria dos bugs de parsing aparece: períodos ausentes, ligas renomeadas, um mercado que aparece em um período e não em outro.

Se você mantém uma tabela de mudanças de preço, reproduzir o delta duas vezes não deve duplicar as linhas. A regra do design de armazenamento, inserir apenas quando o preço de uma seleção difere da última linha que você guarda, é exatamente o tipo de invariante que um teste de reprodução reforça.

Ensaie as falhas de propósito

Offline é o único lugar onde a API falha sob comando. Sirva ao seu cliente três respostas enlatadas: um 429 com cabeçalho Retry-After, um 500 e um 200 com JSON truncado. O comportamento esperado vem do guia de limites de taxa: honre o Retry-After exatamente, recue com jitter quando não houver cabeçalho, limite as tentativas para que um ciclo ruim falhe em vez de bloquear o próximo, e trate um 200 com envelope inválido como erro, não como um board vazio.

Registre o que seu cliente faz em cada caso. Um cliente que insiste através de um 429 enlatado vai insistir através de um real em dia de partida, quando a folga mais importa.

Teste o caminho de reinício

Mate o processo no meio do ciclo, reinicie-o e verifique se o polling retoma a partir do cursor armazenado em vez de reler um board completo. O guia de integração reserva snapshots completos para a primeira inicialização e a recuperação de desastres; seu teste deve provar que o estado estacionário realmente funciona assim.

Se você mantém um mapa de últimos preços em memória para deduplicação, reconstrua-o a partir da tabela na inicialização e confirme que o primeiro poll após o reinício não grava mudanças fantasmas.

O que ainda precisa da API ao vivo

Fixtures não provam frescor. Os boards pré-jogo são atualizados no ritmo da fonte, cerca de 30 segundos segundo o guia de capacidade, verificado em 2026-09-29, então fazer polling mais rápido não compra nada, e só uma execução ao vivo mostra a cadência real das mudanças. Termine o ensaio com uma pequena rodada ao vivo na chave gratuita: um board, alguns polls com um minuto de intervalo, depois compare os tamanhos de delta observados com as suas gravações.

Grave uma vez, reproduza muitas, falhe de propósito. A cota que você não gasta testando é a cota que sua primeira semana ao vivo guarda para si.