Carga de Programas y Fixtures
Precarga programas y fixtures de cuentas deterministas para que cada ejecución de prueba comience desde el mismo estado en la cadena.
//
Busca en todas las páginas de la documentación
Precarga programas y fixtures de cuentas deterministas para que cada ejecución de prueba comience desde el mismo estado en la cadena.
Tarjeta de receta de referencia rápida - lista para copiar y pegar.
solana-test-validator --reset \
--bpf-program <PROGRAM_ID> target/deploy/my_program.so \
--account <PUBKEY> fixture.json
anchor testCuándo usar esto:
.so de terceros con IDs fijos.# 1. Exportar una cuenta fixture una vez desde devnet/mainnet
solana account <CONFIG_PUBKEY> --output json-compact > config-fixture.json
# 2. Iniciar el validador con programa + fixture
PROGRAM_ID=$(solana-keygen pubkey target/deploy/my_program-keypair.json)
solana-test-validator --reset \
--bpf-program "$PROGRAM_ID" target/deploy/my_program.so \
--account <CONFIG_PUBKEY> config-fixture.json
# 3. Ejecutar pruebas contra estado conocido
solana config set --url http://127.0.0.1:8899
anchor test --skip-local-validatorLo que esto demuestra:
--bpf-program carga tu bytecode en el génesis.--account inyecta lamports/propietario/datos desde JSON exportado..so descargados de solana program dump.[test.validator] de Anchor.toml.| Fuente | Comando | Caso de uso |
|---|---|---|
| Exportación RPC | solana account --output json | Configuraciones realistas |
| JSON escrito a mano | editor | Estado sintético mínimo |
| Transacciones de configuración de prueba | hooks before | Dinámico pero más lento |
| LiteSVM set_account | API Rust | Pruebas unitarias rápidas |
# Ejemplo de Anchor.toml
# [test.validator]
# url = "https://api.mainnet-beta.solana.com"
# clone = ["<MINT>", "<ORACLE>"]before no deterministas - las pruebas fallan cuando el orden de configuración cambia. Solución: preferir fixtures estáticos para las puertas de control de CI.solana account de origen.declare_id! y la clave pública del par de claves.| Alternativa | Usar Cuándo | No Usar Cuándo |
|---|---|---|
--clone desde mainnet | Cuando se necesita un diseño en vivo | Pruebas pequeñas solo de configuración |
| Instrucciones de configuración en cadena | Pruebas de flujos de inicialización | Costo repetido de CI |
| LiteSVM | Lógica pura del programa Rust | Clientes RPC de extremo a extremo |
| Despliegue compartido en devnet | QA manual del equipo | Verificaciones automatizadas de PR |
Patrón común: tests/fixtures/ confirmados en git con origen documentado.
Sí, bajo [test.validator] con el array clone y url para el clúster de origen.
Repetir los flags --bpf-program <ID> <SO> en una sola línea de comandos del validador.
El JSON exportado incluye lamports - asegúrate de que haya suficientes para el alquiler al inyectar manualmente.
Las transacciones pueden mutar el estado después del arranque - los fixtures son solo condiciones iniciales.
No confirmes datos privados de usuario - sanitiza las claves públicas y los saldos en los fixtures compartidos.
La bifurcación de Surfpool reduce la necesidad de fixtures manuales - sigue siendo útil para superposiciones de configuración personalizadas.
Cumple con los límites de tamaño de cuenta - las cuentas grandes ralentizan el arranque proporcionalmente.
Carga .so en el ID del programa; la autoridad de actualización se comporta según las reglas del cargador en localnet.
Vuelve a ejecutar solana account --output json contra un estado de clúster conocido y actualiza la versión del archivo en el mensaje de commit.
Versiones de Stack: Esta página fue 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, y LiteSVM 0.6.x.
Revisado por Chris St. John·Última actualización: 16 jul 2026