Skip to content

test(native): add LiteSVM tests for the 3 JS-only native examples (migrating escrow off solana-program 1.18)#50

Merged
mikemaccana merged 3 commits into
mainfrom
claude/wonderful-einstein-HmaHM
Jun 4, 2026
Merged

test(native): add LiteSVM tests for the 3 JS-only native examples (migrating escrow off solana-program 1.18)#50
mikemaccana merged 3 commits into
mainfrom
claude/wonderful-einstein-HmaHM

Conversation

@mikemaccana

Copy link
Copy Markdown
Collaborator

Summary

Follow-up to #48. Three native examples had no real test coverage: their only tests were TypeScript suites that import { test } from "node:test" but run under ts-mocha, so mocha discovered zero tests, printed "0 passing", and exited 0 (false green). This PR gives each one a real LiteSVM Rust integration test, matching the pattern used by the basics/*/native examples.

All tests were built (cargo build-sbf) and run (cargo test) locally against the CI toolchain (Solana 3.1.14 / platform-tools v1.52), and pass cargo fmt --check + cargo clippy -D warnings.

Changes

tokens/token-extensions/multiple-extensions/native — LiteSVM test that creates a Token-2022 mint and asserts the MintCloseAuthority (with the expected authority) and NonTransferable extensions are present.

tokens/token-extensions/default-account-state/native — LiteSVM test that creates a Token-2022 mint and asserts the DefaultAccountState extension was flipped from Frozen to Initialized.

finance/escrow/native — required a program migration before it could be tested:

  • It was pinned to solana-program =1.18.17, whose curve25519-dalek 3.2.1 requires zeroize <1.4. Any modern test dep (litesvm / solana-keypair 3.x → ed25519-dalek 2zeroize >=1.5) conflicts with that, so no LiteSVM test could be added while on the old toolchain.
  • Migrated to the same modern deps the rest of the repo uses: solana-program 4.0 + solana-system-interface, and the lightweight spl-token-interface / spl-associated-token-account-interface client crates.
  • The deprecated spl_token::instruction::transfer (which would fail clippy -D warnings) is replaced with transfer_checked, reading decimals from the mint accounts the instructions already receive — the external account interface is unchanged.
  • AccountInfo::realloc(0, true)resize(0) (renamed in solana 4.0).
  • Added a LiteSVM test covering the full make-offer / take-offer flow: mint two tokens, make an offer (assert the vault is funded), take it, and assert the vault + offer accounts are closed and both parties received the expected amounts.

Notes

  • LiteSVM bundles the SPL Token / Token-2022 programs, so no new fixtures are committed. CI builds each program .so in the build-and-test step before cargo test, matching the existing native examples (program .so binaries are not tracked).
  • The false-green TypeScript suites are left in place; happy to remove them in a follow-up now that real Rust coverage exists.

https://claude.ai/code/session_013dpnF6uSGWXjkJJZseqzcP


Generated by Claude Code

claude added 3 commits June 4, 2026 19:51
…s and default-account-state native examples

These two native examples only had TypeScript tests that import from
`node:test` while being run under `ts-mocha`, so mocha discovered zero
tests, printed "0 passing", and exited 0 — the suites were never actually
executed in CI (false green).

Add real Rust LiteSVM integration tests (matching the pattern used by the
basics native examples) that exercise each program end to end:

- multiple-extensions: creates a Token-2022 mint and asserts the
  MintCloseAuthority (with the expected authority) and NonTransferable
  extensions are present.
- default-account-state: creates a Token-2022 mint and asserts the
  DefaultAccountState extension was flipped from Frozen to Initialized.

LiteSVM bundles the SPL Token-2022 program, so no extra fixtures are
needed beyond the program .so that CI builds via `cargo build-sbf`.
…iteSVM test

The escrow native program was pinned to solana-program =1.18.17, whose
curve25519-dalek 3.2.1 dependency requires zeroize <1.4. That conflicts
with any modern test dependency (litesvm / solana-keypair 3.x pull
ed25519-dalek 2 -> zeroize >=1.5), so the program could not be given a
LiteSVM Rust test while on the old toolchain. Its only existing test was a
TypeScript suite that imported from `node:test` but ran under `ts-mocha`,
so it executed zero tests (false green).

Migrate the program to the same modern dependencies the rest of the repo
uses:
- solana-program 4.0 + solana-system-interface for the system program
- spl-token-interface / spl-associated-token-account-interface (the
  lightweight client crates built on the split solana-* crates)

Required code changes:
- The deprecated `spl_token::instruction::transfer` (which would fail
  `clippy -D warnings`) is replaced with `transfer_checked`, reading the
  decimals from the mint accounts the instructions already receive. The
  external account interface is unchanged.
- `AccountInfo::realloc(0, true)` -> `resize(0)` (renamed in solana 4.0).

Add a LiteSVM integration test covering the full make-offer / take-offer
flow: mint two tokens, make an offer (asserting the vault is funded), take
it, and assert the vault + offer accounts are closed and both parties
received the expected amounts.
…st tests

The three native examples now have real LiteSVM Rust tests, so their
TypeScript suites — which imported from `node:test` but ran under
`ts-mocha`, executing zero tests (false green) — are removed along with
their now-unused JS tooling (ts-mocha, mocha, chai, solana-bankrun, etc.)
and tsconfig.json. `build-and-test` is rewired to just build the program
.so into tests/fixtures, which is what the LiteSVM `cargo test` consumes;
the empty lockfiles keep `pnpm install --frozen-lockfile` passing in CI.

Also fix the stale .gitignore exception path for the escrow Cargo.lock
(escrow moved from tokens/ to finance/) and document the real reason it
stays tracked (standalone, non-workspace crate).
@mikemaccana mikemaccana merged commit d6b766a into main Jun 4, 2026
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants