テストとローカル検証

導入

いきなり本物のネットワーク（dAppが動く公開環境）にデプロイして試すのは危険です。Solana開発では、自分のPC上で動く模擬のブロックチェーンでまず検証し、それから公開のテスト環境、最後に本番へと段階を踏みます。

説明

Solanaには solana-test-validator という、ローカルで動く1台構成の検証ノードがあります。本物のブロックチェーンと同じ挙動をしつつ、ネットワーク通信が発生しないため高速です。Anchorの anchor test コマンドは、この検証ノードの起動・プログラムのデプロイ・テストの実行・後片付けまでを自動でやってくれます。

sequenceDiagram
    participant Dev as 開発者
    participant CLI as anchor test
    participant Val as solana-test-validator
    participant Prog as デプロイされたプログラム
    participant T as TypeScriptのテストコード
    Dev->>CLI: anchor test を実行
    CLI->>Val: ローカル検証ノードを起動
    CLI->>Val: ビルド済みプログラムをデプロイ
    CLI->>T: テストスクリプトを実行
    T->>Prog: 命令を呼び出す(initialize等)
    Prog-->>T: 結果/エラーを返す
    T->>T: assertで期待値と比較
    CLI-->>Dev: テスト結果を表示
    CLI->>Val: 検証ノードを終了

ローカルでの検証が済んだら、次は devnet（Solanaが公式に用意しているテスト用ネットワーク）にデプロイして、より本番に近い環境で動作を確認します。devnetのSOL（手数料支払いに使う通貨）は solana airdrop コマンドで無料配布してもらえるため、安心して試せます。

# クラスタをdevnetに向ける（Anchor.tomlのclusterでも設定可能）
solana config set --url devnet

# devnetのSOLを受け取る（テスト用、価値はない）
solana airdrop 2

# devnetへデプロイ
anchor deploy

Anchor.toml には [programs.localnet] や [programs.devnet] のようにクラスタごとのプログラムIDを書けます。ローカル→devnet→（十分検証してから）mainnet-beta（本番） という順で段階を踏むのが、Solana開発の基本の型です。

演習

なぜ「いきなり本番（mainnet-beta）にデプロイしてテストする」ことを避けるべきなのか、自分の言葉で説明してみましょう。