solana/proposals/src/testing-programs.md

Testing Programs

Applications send transactions to a Solana cluster and query validators to confirm the transactions were processed and to check each transaction's result. When the cluster doesn't behave as anticipated, it could be for a number of reasons:

• The program is buggy
• The BPF loader rejected an unsafe program instruction
• The transaction was too big
• The transaction was invalid
• The Runtime tried to execute the transaction when another one was accessing the same account
• The network dropped the transaction
• The cluster rolled back the ledger
• A validator responded to queries maliciously

The Transact Trait

To troubleshoot, the application should retarget a lower-level component, where fewer errors are possible. Retargeting can be done with different implementations of the Transact trait.

When Futures 0.3.0 is released, the Transact trait may look like this:

trait Transact {
    async fn send_transactions(txs: &[Transaction]) -> Vec<Result<(), TransactionError>>;
}

Users send transactions and asynchrounously await their results.

Transact with Clusters

The highest level implementation targets a Solana cluster, which may be a deployed testnet or a local cluster running on a development machine.

Transact with the TPU

The next level is the TPU implementation of Transact. At the TPU level, the application sends transactions over Rust channels, where there can be no surprises from network queues or dropped packets. The TPU implements all "normal" transaction errors. It does signature verification, may report account-in-use errors, and otherwise results in the ledger, complete with proof of history hashes.

Low-level testing

Testing with the Bank

Below the TPU level is the Bank. The Bank doesn't do signature verification or generate a ledger. The Bank is a convenient layer at which to test new on-chain programs. It allows developers to toggle between native program implementations and BPF-compiled variants. No need for the Transact trait here. The Bank's API is synchronous.

Unit-testing with the Runtime

Below the Bank is the Runtime. The Runtime is the ideal test environment for unit-testing. By statically linking the Runtime into a native program implementation, the developer gains the shortest possible edit-compile-run loop. Without any dynamic linking, stack traces include debug symbols and program errors are straightforward to troubleshoot.