T12 · テストとデプロイ

現実の問題

ユーザーからあるステーブルコインを預かり、レンディングプロトコルへ預け入れて、預入証明をユーザーへ返すコントラクトを作ったとします。

テストは入念に書きました。偽のトークンと偽のレンディングプロトコルを用意し、34 ケース、カバレッジ 97%、すべて成功です。

ところがメインネットへデプロイすると、最初の実取引が revert します。

半日調べてようやく原因が分かりました。実際のステーブルコインは、既存の承認額がゼロでない状態で再度承認すると失敗します。 標準に沿って作った偽トークンにはその挙動がありません。実物は標準に完全には従っていなかったのです（T9 で扱った種類の落とし穴です）。

修正して再デプロイすると、2 件目の取引も revert しました。実際のレンディングプロトコルでは、この資産に最低預入額が設定されており、それ未満は拒否されます。偽プロトコルにはその挙動もありませんでした。

3 回目のデプロイ後、最もつらい問題に気付きます。管理権限が、デプロイスクリプトで使った一時アドレスに残っていました。 権限移管の処理は書いたものの、成功したかを何も検証していなかったのです。

3 つの問題には共通点があります。

問題は自分のコードではなく、世界についての自分の想定にありました。そしてテストも、その想定に沿って書かれていました。

97% というカバレッジは、コードが実行されたことを示します。想定が正しいことは何一つ証明していません。

では、想像した世界ではなく、実際の世界に対してテストを実行するにはどうすればよいでしょうか？

思考実験

公開前の準備を、4 段階の飛行訓練に置き換えて考えます。

第 1 段階：紙の上で計算する。 風速、重量、滑走路の長さから離陸距離を計算します。速く、安く、数式の正しさを確認できます。ただし数値の出所は検証できません。計算が正しくても、入力した風速が違えば山に衝突します。

第 2 段階：シミュレーターで飛ぶ。 飛行機、滑走路、管制塔を作り、手順を通して実行します。「脚を格納するとフラップが格納できなくなる」といった、部品同士の問題を発見できます。ただし滑走路も自作なので、実際の滑走路にある穴は再現されていません。

第 3 段階：実際の空港をシミュレーターへ取り込む。 自分で滑走路を作らず、実在する空港の滑走路、地形、航法施設をそのまま取り込み、そこで飛びます。

この段階が本章の中心です。 コードはローカルで実行されますが、やり取りする相手は現実の状態です。実際のトークン、プロトコル、パラメータ、独特な挙動を扱います。最初の 2 段階で見つけられなかった問題が、ここで姿を現します。

第 4 段階：砂袋を載せて、本当に一度飛ぶ。 実際のお金を使わない環境で、デプロイ、検証、権限移管まで、公開手順を一通り実行します。

4 段階の役割は明確です。

• 最初の 2 段階は、自分のロジックを検証します。
• 第 3 段階は、自分の想定を検証します。
• 第 4 段階は、自分の手順を検証します。

それぞれ異なる種類の誤りなので、一つの手段ですべてを検証することはできません。

さらに、どの段階よりも重要で、段階とは無関係な点があります。

コントラクトの入口はすべて公開されています。そのため「正しく実行できるか」以上に、「正しく拒否できるか」が重要です。

正常に実行する経路は一つで、必ずテストします。正しく拒否すべき経路は何十もあり、一つでも漏れると、誰もが直接呼び出せる穴になります。

あなたが決める

コントラクトが実際のプロトコルとやり取りします。公開前にどうテストしますか？

結果を観察する

4 つの選択肢は 4 段階の優劣ではなく、互いに独立した 2 つの軸です。

この表から持ち帰ってほしいのは、次の一文です。

カバレッジはコードがどれだけ実行されたかを測り、想定がどれだけ検証されたかは測りません。

代役のみで 100% を達成したテスト群は、実際の世界の挙動を何も知らないかもしれません。一方、実際の状態で動く一経路は、分岐の 20% しか網羅しなくても、損失につながる種類の問題を防げます。したがって一つを選ぶのではなく、段階ごとに役割を分けます。

• ロジックと拒否経路は代役で検証する。速いため、多くのケースを書けます。
• 統合は実際の状態で検証する。それだけが想定を確かめられます。
• デプロイは一度の完全なリハーサルで検証する。デプロイも、普段はテストされないコードだからです。

もう一つ、明記すべき帰結があります。書き忘れた拒否ケースこそ、他人が呼び出す入口です。

モデルを作る

公開までのパイプライン

最初の工程に注目してください。失敗ケースを先に、成功ケースを後に書きます。 好みの問題ではなく、順序の問題です。成功ケースから書くと、それを書き終えた時点で完了した気になるからです。

拒否リスト：制限を一つずつテストケースにする

コントラクトを開き、「条件を満たさないと拒否する」箇所をすべて列挙し、それぞれに一つのケースを対応させます。

最後は特殊なケースです。テスト道具として「悪意あるコントラクト」を専用に作ります。コールバックを受けたとき、禁止される操作を行うことだけが役目です。再入の全体モデルは T28 で学びますが、このケースは今から必要です。

見落としやすい確認点が 2 つあります。

1. 確認するのは「拒否」であり、「何かのエラー」ではありません。 具体的なエラー型やメッセージを確認します。そうしないと、別の原因で失敗しても成功扱いになる、見せかけの成功ケースが生まれます。これは非常に多い問題です。
2. 拒否後に状態が変わっていないこと。 revert は取引の変更をすべて巻き戻すはずです。主要な状態が変わらないことも確認すると、見つけにくい種類の誤りを捕捉できます。

実際の状態でのテスト：正しく行うべき 3 点

第一に、高さを固定します。 実ネットワークから状態を取得する際は、ブロック高を設定に固定します。固定しないと、十数秒ごとに変わる「現在のチェーン状態」へ依存します。今日成功したケースが来週失敗し、自分のコードには存在しない問題の調査に 2 日かかることになります。

第二に、身元と残高を用意します。 テスト用アカウントは、実際の状態では資金を持っていません。方法は 2 つあります。

• 対象資産を大量に持つ実在アドレスを見つけ、その身元で取引します。大半のテストフレームワークに、任意アドレスとして呼び出す機能があります。
• ストレージを書き換えて残高を設定します。速い方法ですが、残高がどのスロットにあるかを知る必要があります（レイアウトは T8）。

第三に、エラーがないことではなく、実際の結果を確認します。 「revert しなかった」だけでは、ほとんど情報がありません。自分の残高がいくら減ったか、何の証明が返されたか、プロトコルの記帳がどう変わったかを確認します。

完全な統合テスト経路は次のようになります。

1. 実ネットワークの固定ブロック高から状態を取得する
2. 自分のコントラクトをデプロイする
3. テストアカウントへ実際の資産を用意する
4. 操作前の関係する残高と状態をすべて記録する
5. コントラクトを呼び出し、一連の業務経路を通す
6. 自分の残高、相手の残高、証明の数量、プロトコルの記帳を個別に照合する
7. 逆方向の経路（引き出し、償還）も通し、開始点へ戻れることを確認する

第 7 工程は省略されやすく、問題にもなりやすいものです。預けられることと引き出せることは別です。実際に試して初めて、引き出せないと分かります。

ランダム入力と不変条件：「すべての入力について」を実行可能な確認にする

通常のケースは「この入力なら、この出力になる」というものです。ランダムテストは逆に、任意の入力でも、ある性質が常に成立するかを問います。

資金を保有するほぼすべてのコントラクトで使える、代表的な性質があります。

コントラクトが実際に持つ資産  が  全ユーザーの記帳額の合計以上
全保有者の残高の合計  が  総供給量と等しい
任意の操作列の後にアカウントが引き出せる額  が  預けた額以下
「預入後すぐ引き出す」純効果  が  何もしない場合より有利ではない
管理者だけが変えられるパラメータ  が  1 万回のランダム呼び出し後も変わらない

最後の性質は過小評価されています。すべての公開入口へ 1 万回のランダム呼び出しを行い、その後で不変条件を調べます。 非常に安く効果の高いテストで、想像しなかった呼び出し順序の問題が見つかります。

実務上の注意点は 2 つです。

• 失敗を再現できるようにする。 失敗させた乱数シードと入力列を記録し、通常のテストケースとして固定します。
• 不変条件の範囲を明確にする。 「コントラクトの残高が記帳合計以上」という条件は、入口を経由しない直接送金で破れる場合があります。その際は条件を調整するか、実際の欠陥だと認める必要があります。

デプロイも、普段テストされないコードである

デプロイスクリプトは、プロジェクトで唯一「一度だけ実行し、間違えても直せず、テストもない」コードになりがちです。冒頭の 3 番目の問題はここで起きました。

適切なスクリプトには、次の要件があります。

最も重要なのは 3 行目です。スクリプトの末尾には、一連のアサーションを書くべきです。「デプロイ完了」と表示するだけでは足りません。

assert コントラクトの owner == 設定したマルチシグアドレス
assert コントラクトの admin != デプロイ者アドレス
assert 主要パラメータ == 設定値
assert コントラクトは停止中（停止してから公開する手順の場合）
assert 外部依存のアドレス == 設定アドレス、かつそのアドレスにコードがある

最後は特に見落としやすい点です。渡した外部アドレスには、そのチェーン上でコントラクトが存在しないかもしれません。 空アドレスへの依存は、デプロイ時にエラーにならず、最初のユーザー取引で初めて壊れます。

手順上のルールもあります。デプロイスクリプトは、実際の状態を取り込んだローカル環境で、先にリハーサルします。 同じ設定とスクリプトで、デプロイからアサーションまで完走させます。お金を使う前に、特に高くつく設定、アドレス、権限の誤りを発見できます。

何と呼ぶか

実践

<テストフレームワークのフォーク引数> --fork-url <アーカイブ RPC アドレス> --fork-block-number <選んだブロック高>

方法 1：保有者の身元で呼び出す
  対象トークンを大量に持つ実在アドレスを探す
  フレームワークの「任意アドレスとして取引する」機能を使う
  そこからテストアカウントへ一部を送る

方法 2：ストレージを直接書き換える
  残高マッピングのスロットを見つける（配置規則は T8）
  フレームワークの「任意スロットへ書き込む」機能を使う

ケース 1：金額 0 で呼び出し、拒否と状態不変を確認
ケース 2：承認額なしで呼び出し、拒否を確認
ケース 3：非管理者アドレスから管理関数を呼び出し、拒否を確認

コントラクトを開き、「条件を満たさないと拒否する」箇所を数える。
テストの中で、拒否を確認するケースを数える。
二つの数は近いはず。

コントラクトが実際に持つ資産数量  が  全ユーザーの記帳額合計以上

AI Lab

第 1 段階：
これは私のコントラクトのソースです。テスト群を生成してください。
すべての拒否条件を先に列挙し、それぞれ拒否を確認するケースを作り、
その後で成功経路を書いてください。各ケースの検証対象も説明してください。

第 2 段階：
生成したケースをソースと一行ずつ照合し、表にしてください。
各 require / revert / 権限確認に対応するケースはどれですか？
対応ケースがない箇所は別に列挙してください。

第 3 段階：
このコントラクトが実際の外部プロトコルとやり取りし、テストでは代役を使うとします。
代役と実際の依存先のどの種類の挙動の違いが、テスト成功と本番失敗を招きますか？
種類ごとに具体例を一つ示し、フォーク環境での検証方法を説明してください。

実例

変数を一つ変える

持ち帰る問い

章末チェック