I spent a week building a counter program in Anchor — the Rust framework
for writing Solana programs. By the end I had two instructions, one
authorization constraint, and a test suite I could actually trust. Here
is what I built, how I tested it, and the moment I proved the tests
were real.

Start Here: The Accounts Struct

If you come from Web2, this is the part that looks the strangest:

#[derive(Accounts)]
pub struct Initialize {
    #[account(
        init,
        payer = authority,
        space = 8 + Counter::INIT_SPACE,
    )]
    pub counter: Account,
    #[account(mut)]
    pub authority: Signer,
    pub system_program: Program,
}

In a Web2 backend, your handler receives a request object and talks
to a database. On Solana, there is no database; there are accounts.
Every account your instruction needs to read or write must be declared
upfront, before the handler runs. Anchor validates them before your
code ever executes.

Here is what each field does:

• counter — the account being created. The init constraint tells Anchor to make a CPI to the System Program, allocate 8 + Counter::INIT_SPACE bytes, and fund it from authority. The 8 is for the discriminator Anchor stamps on every account so the program can later verify "this is mine."
• authority — the wallet signing and paying for the transaction. mut because its SOL balance is decreasing to fund the new account.
• system_program — required any time you create accounts. Anchor checks that the address matches the real System Program.

The accounts struct is the schema. The handler is the logic.

The Handlers

pub fn initialize(ctx: Context) -> Result {
    let counter = &mut ctx.accounts.counter;
    counter.authority = ctx.accounts.authority.key();
    counter.count = 0;
    Ok(())
}

ctx.accounts gives you typed access to every account declared in
the struct. The handler is short because Anchor already did the hard
work: allocating the account, checking the signer, paying the rent.
Your code just sets the initial values.

pub fn increment(ctx: Context) -> Result {
    let counter = &mut ctx.accounts.counter;
    counter.count = counter.count
        .checked_add(1)
        .ok_or(error!(ErrorCode::ArithmeticOverflow))?;
    Ok(())
}

The accounts struct for increment has a constraint worth paying
attention to:

#[derive(Accounts)]
pub struct Increment {
    #[account(mut, has_one = authority)]
    pub counter: Account,
    pub authority: Signer,
}

has_one = authority tells Anchor: before this handler runs, check
that counter.authority == authority.key(). If the wallet signing
the transaction does not match the wallet stored on the counter,
the transaction is rejected. My handler never sees a bad caller —
the constraint rejects them first.

This is the Solana equivalent of a 403 check, but it is declarative
and enforced by the runtime. There is no application layer to
accidentally bypass.

The Tests

I used LiteSVM — an in-process
Solana VM that runs your compiled program against a fresh ledger in
milliseconds. No devnet, no flakiness, no airdrop required.

Happy path

#[test]
fn initialize_then_increment() {
    let mut svm = LiteSVM::new();
    // ... load program, airdrop, create keypairs ...

    svm.send_transaction(init_tx).unwrap();
    svm.send_transaction(inc_tx).unwrap();

    let account = svm.get_account(&counter_kp.pubkey()).unwrap();
    let parsed = counter::Counter::try_deserialize(
        &mut account.data.as_slice()
    ).unwrap();

   assert_eq!(parsed.count, 1);
   assert_eq!(parsed.authority, authority.pubkey());
 }

This test would fail if increment stored the wrong number, or if
initialize set the wrong authority. It proves both instructions
work correctly together.

Failure path

#[test]
fn increment_fails_when_wrong_authority_signs() {
    // authority_a creates the counter
    svm.send_transaction(init_tx).expect("initialize should succeed");

    // authority_b tries to increment it
    let bad_tx = build_increment_tx(&svm, program_id,
        &authority_b, counter.pubkey());

    let result = svm.send_transaction(bad_tx);
    assert!(result.is_err(),
        "increment should fail when signed by the wrong authority");
}

This test would fail if I removed or weakened the has_one = authority
constraint. It proves the gate is real, not just assumed.

The Experiment That Made the Tests Real

A passing test suite is a story. The question is whether it tells the
truth.

On the last day of the week I planted bugs on purpose, one at a time,
and watched the suite catch them.

The most instructive experiment: I changed checked_add(1) to
checked_add(2) in the increment handler. The transaction still
succeeded — no error, no panic. But the stored value was wrong.

The test output:
test initialize_then_increment ... FAILED
thread panicked at:

assertion left == right failed
left: 1
right: 2

One character change in production code. One specific failure with a
specific line number pointing exactly at the assertion that caught it.
That is what assertions are for.

Then I removed the has_one = authority constraint entirely. The
happy-path test stayed green — it uses the correct authority. But:

test increment_fails_when_wrong_authority_signs ... FAILED

increment should fail when signed by the wrong authority

The wrong-signer transaction now succeeded, and the test that expected
a rejection panicked. Without that failure test, I would have silently
shipped a program that lets anyone increment anyone else's counter.
The negative test is the only reason I would have known.

Both times I put the code back, ran the suite, and got green. The
suite told the truth both times.

What I Would Build Next

The counter account in this program lives at a random keypair's
address. That means the client has to remember which keypair holds
which user's counter — messy in practice. The natural next step is
Program Derived Addresses (PDAs): deterministic addresses derived
from the user's wallet and a seed string, so any client can find any
user's counter without storing a keypair.

After that: a decrement instruction, a reset instruction, and
then connecting the program to a TypeScript client so it can run
on devnet with a real wallet.

Resources

• Anchor framework — the framework used throughout
• Anchor account constraints reference — full list of constraints including has_one, init, mut
• LiteSVM — the in-process test harness
• Solana docs — accounts model primer

This post is part of *#100DaysOfSolana*. Building on Solana every
day — follow along or jump in any time.