SVM Reddit Mentions | ChartExchange

**Source:** [https://x.com/accretion\_xyz/status/2102386884710207882](https://x.com/accretion_xyz/status/2102386884710207882)
https://preview.redd.it/dr6vtgm9r3rh1.png?width=680&format=png&auto=webp&s=818370a82c9f0329019c9bca03ebb3d984c36274
A test that initializes one account and prints "success" proves that the program deployed and one path did not explode. That is about it.
Every Solana instruction receives attacker-controlled instruction data and an attacker-selected account list. Your test suite should map every assumption you make about those inputs. Default to instruction tests and end-to-end flows: execute the public instructions in an SVM (LiteSVM or Mollusk) and check the state they leave behind. Add unit tests only where isolated logic, especially math, deserves them.
Here is what that looks like in practice.
1. Give every instruction its own complete happy path
One row per instruction, built from your IDL. For each one, use the smallest legitimate setup and assert all observable effects: the tx succeeds, every changed account holds the exact expected data, lamport and token deltas are correct, authorities and mints stay correct, closed accounts are gone with rent sent to the right place, and unrelated accounts did not change. Calling an instruction once inside a larger flow does not make it covered.
2. Test full user lifecycles
Per-instruction tests reset the world constantly, but plenty of bugs need history. Write at least one test that runs the same user through create, deposit, act, advance time, partial withdraw, full withdraw, and close, then verify the account cannot be used afterward. Create that state through the public instructions, not by injecting it. Assert invariants after every step (assets equal liabilities, shares sum correctly, no balance wraps). Add a two-user interleaved flow to catch global-field bugs and account aliasing. And test atomic composition: if a later instruction fails, earlier changes in the same tx must revert.
3. Make failed tests prove the right thing
For every instruction, list each trust assumption (missing signer, wrong authority, wrong PDA, wrong owner, wrong mint, attacker-selected CPI, reordered remaining\_accounts, wrong state) and break them one at a time. Every failure test must prove three things: the call failed, it failed with the exact expected error, and program state plus balances are unchanged apart from documented fee or nonce effects. is\_err() alone proves nothing. Maybe the auth check worked, or maybe the tx died earlier because you forgot a writable account. Assert the error code, and snapshot accounts before and after.
4. Test one unit away from success
The best unhappy-path tests are one unit away from valid. They catch > vs >=, rounding mistakes, and stale timestamps. For a rule min <= amount <= max, test min-1, min, min+1, max-1, max, max+1. Always test the valid side of every boundary, or a failing test may only prove the instruction is broken for everyone.
5. Use unit tests where they earn their place
Math with rounding or overflow is the classic case. Watch out for AI-generated unit tests that copy the implementation's formula into the assertion, so the same mistake appears on both sides and the test passes. Use expected values worked out from the intended rule instead.
6. Turn every bug and audit finding into a regression test
Before you fix a bug, reproduce it with a test that fails on the vulnerable code for the right reason. Put it at the cheapest layer that faithfully reproduces it. For a security finding, reproduce the consequence through the public instruction: if Alice could drain Bob, the regression should require an authorization error and an unchanged Bob balance. Keep it forever.
7. Add a real integration layer, and use coverage as a searchlight
Exercise the interfaces that ship: the compiled binary, generated clients, the IDL, transaction construction, RPC, CPI targets, and Token-2022 variants. Read coverage reports instead of chasing one big percentage. Then do one falsification check: flip a boundary or remove a state update and confirm the right test fails. That catches tests that run a lot of code and prove nothing.
Yes, you will end up with hundreds of tests for an average program. That is normal, and far easier to live with than one mainnet bug nobody can reproduce.
Full version, with code, tables, and framework specifics:
[https://accretion.xyz/blog/solana-program-test-suite](https://accretion.xyz/blog/solana-program-test-suite)