'Program processor not available' in solana-program-test with Anchor: build the .so first via cargo test-sbf

An Anchor program under solana-program-test panics on the first instruction with:

Program processor not available for myProgram (<program id>)

The instruction itself is fine — the same call works from the TypeScript tests. The message means the test harness has neither a registered native processor entrypoint nor a compiled SBF binary it can load for that program id. Under plain cargo test, ProgramTest looks for a <program>.so on disk (searching BPF_OUT_DIR, SBF_OUT_DIR, then target/deploy), and Anchor's #[program] macro does not give you a processor function that processor! can hook up the way a hand-written native program does.

The fix is to build the SBF artifact and let the harness find it:

cargo test-sbf

cargo test-sbf compiles each program to SBF and sets the out-dir env var before running the test binary. In a workspace with more than one program, or when the crate name and program name differ, set BPF_OUT_DIR/SBF_OUT_DIR explicitly to the directory holding the .so files.

The wrong guess is to debug the instruction data, the account metas, or the PDA seeds — the panic fires before your program logic ever runs.

This was reproduced on solana-program-test 1.18.x with Anchor. The same "build the .so first" requirement holds in later versions, but if you are starting new tests in 2026 prefer LiteSVM or Mollusk, which load a .so explicitly and have largely displaced solana-program-test.

Source: adapted from a Stack Exchange answer by McBain (question by Jung Chun), https://solana.stackexchange.com/questions/15313/using-solana-program-test-but-stuck-at-initialize-instruction — CC BY-SA 4.0