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.
Receta
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:
- Pipelines de CI que no deben depender de la disponibilidad de devnet.
- Pruebas que requieren saldos de tokens o cuentas de configuración conocidos.
- Carga de binarios
.sode terceros con IDs fijos. - Compartir archivos de fixtures entre miembros del equipo.
Ejemplo de Trabajo
# 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-programcarga tu bytecode en el génesis.--accountinyecta lamports/propietario/datos desde JSON exportado.- Las pruebas se validan contra una configuración estable en lugar de un estado aleatorio de devnet.
Inmersión Profunda
Cómo Funciona
- El JSON de fixture codifica los campos de la cuenta que el validador aplica al inicio.
- Los programas pueden ser compilaciones locales o
.sodescargados desolana program dump. - Las pruebas de Anchor pueden iniciar el validador con flags personalizadas a través de la sección
[test.validator]deAnchor.toml. - LiteSVM 0.6.x ofrece fixtures a nivel de código para pruebas unitarias de Rust sin RPC.
Fuentes de Fixtures
| 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 |
Notas de bash
# Ejemplo de Anchor.toml
# [test.validator]
# url = "https://api.mainnet-beta.solana.com"
# clone = ["<MINT>", "<ORACLE>"]Trampas Comunes
- Hooks
beforeno deterministas - las pruebas fallan cuando el orden de configuración cambia. Solución: preferir fixtures estáticos para las puertas de control de CI. - Propietario incorrecto en el JSON de fixture - la cuenta se rechaza al cargar. Solución: copiar el propietario exacto de
solana accountde origen. - Deriva de fixture - la cuenta de devnet exportada cambia externamente. Solución: versionar los archivos de fixture en git con comentarios sobre la ranura de origen.
- Fixtures sobredimensionados - git lento y arranque del validador. Solución: recortar datos o generarlos programáticamente en las pruebas.
- Desajuste de ID de programa en bpf-program - los clientes llaman a la dirección incorrecta. Solución: sincronizar
declare_id!y la clave pública del par de claves.
Alternativas
| 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 |
Preguntas Frecuentes
¿Dónde viven los archivos JSON de fixture?
Patrón común: tests/fixtures/ confirmados en git con origen documentado.
¿Puede Anchor.toml configurar clones?
Sí, bajo [test.validator] con el array clone y url para el clúster de origen.
¿Cómo cargo múltiples programas?
Repetir los flags --bpf-program <ID> <SO> en una sola línea de comandos del validador.
¿Los fixtures incluyen saldo exento de alquiler?
El JSON exportado incluye lamports - asegúrate de que haya suficientes para el alquiler al inyectar manualmente.
¿Puedo actualizar un fixture a mitad de la prueba?
Las transacciones pueden mutar el estado después del arranque - los fixtures son solo condiciones iniciales.
¿Cómo comparto fixtures de forma segura?
No confirmes datos privados de usuario - sanitiza las claves públicas y los saldos en los fixtures compartidos.
¿Funciona esto con Surfpool?
La bifurcación de Surfpool reduce la necesidad de fixtures manuales - sigue siendo útil para superposiciones de configuración personalizadas.
¿Qué tan grandes pueden ser los datos de fixture?
Cumple con los límites de tamaño de cuenta - las cuentas grandes ralentizan el arranque proporcionalmente.
¿Puedo cargar programas actualizables?
Carga .so en el ID del programa; la autoridad de actualización se comporta según las reglas del cargador en localnet.
¿Cómo regenero los fixtures?
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.
Relacionado
- solana-test-validator - flags de inicio
- Clonación de Cuentas de Mainnet - instantáneas en vivo
- LiteSVM - fixtures en memoria
- Pruebas contra un Validador - pruebas de integración
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.