Boas Práticas de Desenvolvimento Local
Um resumo condensado das 25 práticas mais importantes de desenvolvimento local extraídas de todas as páginas desta seção.
-
Prefira localnet para CI: Execute
solana-test-validator --resetnos pipelines - evite limites de taxa da devnet (Local Dev Basics). -
Fixe o RPC em Anchor.toml: A URL do provider deve corresponder ao cluster ativo para evitar deploys acidentais na devnet durante
anchor test. -
Sempre --reset no CI: Gênesis determinístico evita testes instáveis por estado anterior do ledger (solana-test-validator).
-
Inicie logs antes das transações: Execute
solana logsem um segundo terminal antes dos envios (Local Logs & Debugging). -
Faça commit dos arquivos de fixture: Versione fixtures JSON com slot de origem documentado (Loading Programs & Fixtures).
-
Minimize conjuntos de clone: Clone apenas contas que sua instrução toca - o tempo de inicialização escala linearmente (Cloning Mainnet Accounts).
-
Use RPC de provider para clones: A busca na mainnet durante o clone precisa de
--urlconfiável com chave de API. -
Combine IDs de programa em todos os lugares: O pubkey de
--bpf-programdeve ser igual adeclare_id!e às constantes do cliente. -
Use LiteSVM em camadas para velocidade: Teste unitário de caminhos quentes no LiteSVM 0.6.x; reserve o validador para integração.
-
Use Surfpool para grafos DeFi: Quando clones explodem, mude para simulação de fork com Surfpool 0.12.0 (Surfpool).
-
Documente a escolha de cluster por PR: Siga Localnet vs Devnet Workflow e registre a decisão.
-
Financie carteiras locais com generosidade: Airdrops locais são gratuitos - teste layouts pesados em aluguel de forma realista.
-
Meça CU localmente: Leia
computeUnitsConsumedantes de definir orçamentos de compute na mainnet. -
Reduza msg! em builds de produção: Ruído de log trunca e desperdiça CU - use feature-gate para logs verbosos.
-
--skip-local-validator de forma intencional: Ao gerenciar validador de longa duração, passe
anchor test --skip-local-validatorde forma consistente. -
Mate validadores órfãos: Libere a porta 8899 antes de reruns no CI - processos obsoletos causam connection refused.
-
Separe diretórios de ledger para experimentos:
--ledgerpor branch de feature ao explorar estado persistente. -
Sincronize pins da toolchain: O validador local deve executar Agave 4.1.1 correspondendo aos artefatos de deploy.
-
Teste transações v0 localmente: Inclua ALTs em testes locais quando a mainnet usa transações versionadas.
-
Não dependa da devnet para gates de CI: Trate devnet como smoke opcional, não como bloqueador de merge.
-
Atualize clones obsoletos: Reinicie o validador quando mudanças de layout na mainnet quebram testes de CPI.
-
Exporte JSON de tx com falha: Anexe a saída de
solana transactionàs issues para reprodutibilidade. -
Demos de carteira na devnet: Aponte o Phantom para RPC da devnet em demos para stakeholders - localhost na localnet é frágil.
-
Sonde a mainnet com dust: Verificações finais de landing precisam de taxas reais - não substituíveis apenas pela localnet.
-
Combine testes locais com clientes kit: Aponte testes de integração
@solana/kit7.0.0 para a mesma URL de RPC da CLI.
FAQs
Qual é a stack de teste confiável mais rápida?
Testes unitários LiteSVM mais anchor test em localnet com reset - adicione Surfpool apenas para integração DeFi.
O ledger deve persistir localmente?
Apenas ao explorar estado manualmente - CI e verificações de PR devem resetar a cada execução.
Como as práticas locais afetam incidentes na mainnet?
Bons fixtures e medição de CU evitam falhas de landing do tipo "funcionou localmente" - veja a seção de otimização de transações.
Relacionado
- Local Dev Basics - entrada da seção
- solana-test-validator - referência do validador
- Testing Best Practices - política de testes mais ampla
- Solana CLI Best Practices - higiene da CLI
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.