5-4. 実験変更をPR候補に整理する
Level 5では、SetRegularKey を題材にローカルで xrpld の挙動を変えました。最後に、その差分を「学習用の実験」と「PR候補になり得る変更」に分けます。
ローカルで動かした変更を、すべてPRにするわけではありません。xrpld はネットワーク全体の合意に関わるソフトウェアなので、挙動を変える変更には強い理由と合意が必要です。一方で、既存挙動を明確にするテスト追加は、初心者の最初の貢献として現実的です。このページでは、その線引きを実際の差分で練習します。
差分を確認する
Section titled “差分を確認する”まず、xrpld-test で差分を見ます。
cd xrpld-testgit diffLevel 5の流れどおり進めた場合、差分は大きく2種類に分かれます。
| 差分 | 扱い |
|---|---|
SetRegularKey.cpp の preflight() 変更 | 学習用。既存仕様を変えるため、PR候補から外す |
SetRegularKey_test.cpp のテスト追加 | 既存挙動のカバレッジ追加としてPR候補になり得る |
学習用の実装変更を戻す
Section titled “学習用の実装変更を戻す”SetRegularKey.cpp に入れた学習用の条件は戻します。戻した後の preflight() は、実ファイルの元の形に戻ります。
NotTECSetRegularKey::preflight(PreflightContext const& ctx){ if (ctx.tx.isFieldPresent(sfRegularKey) && (ctx.tx.getAccountID(sfRegularKey) == ctx.tx.getAccountID(sfAccount))) { return temBAD_REGKEY; }
return tesSUCCESS;}戻したら、実装側の差分が消えたことを確認します。
git diff -- src/libxrpl/tx/transactors/account/SetRegularKey.cpp何も表示されなければ、学習用の実装変更は戻せています。
PR候補として残すテスト
Section titled “PR候補として残すテスト”5-3 で実験用に追加した testCannotClearRegularKeyInDojoExperiment も、preflight() を戻したら削除し、run() の呼び出しも元に戻します。実験の挙動を前提にしたテストは、そのままでは残せないからです。
代わりに、PR候補として残すなら、既存挙動を壊さずに説明できるテストだけにします。たとえば、Regular Keyを設定してから削除できることを明示するテストです。
voidtestCanClearRegularKey(){ using namespace test::jtx;
testcase("Can clear regular key"); Env env{*this, testableAmendments()}; Account const alice("alice"); Account const bob("bob"); env.fund(XRP(10000), alice, bob);
env(regkey(alice, bob)); env(noop(alice), Sig(bob));
env(regkey(alice, kDisabled)); env(noop(alice), Sig(bob), Ter(tefBAD_AUTH)); env(noop(alice), Sig(alice));}このテストが主張していることは明確です。
aliceはbobを Regular Key に設定できる- 設定後は
bobの署名でaliceのトランザクションを送れる - Regular Keyを削除すると
bobの署名は使えなくなる - マスターキーが有効なら
alice自身の署名は使える
テストを通す
Section titled “テストを通す”テストだけの変更に整理できたら、再度実行します。
cd xrpld-test/.buildcmake --build . --parallel./xrpld --unittest SetRegularKey通ったら、PRに出す前の最小確認として差分をもう一度見ます。
cd xrpld-testgit diff -- src/test/app/SetRegularKey_test.cpp差分がテスト追加だけになっていれば、レビューしやすい変更に近づいています。
PR説明の下書き
Section titled “PR説明の下書き”この変更をPRにするなら、説明は短くて十分です。
Add SetRegularKey coverage for clearing a regular key
This adds an app test that explicitly verifies a regular key can becleared and that the removed regular key can no longer authorizetransactions for the account.「新しい仕様を追加した」とは書きません。既存挙動を明確にテストした、という説明にします。
Level 5のまとめ
Section titled “Level 5のまとめ”ここまでで、次の流れを一周しました。
- 実ファイルを読む
- ローカルで挙動を変える
- テスト結果の変化を見る
- 実験変更とPR候補を分ける
- 小さなテスト追加として整理する
これは、本格的なプロトコル変更に進む前の重要な練習です。次のLevel 6では、新しいトランザクションタイプ、アメンドメント、Invariant Checkのように、本番ネットワークへ影響し得る変更を扱います。
次のステップ
Section titled “次のステップ”本格実装の入口 に進み、プロトコル変更を設計するときに何を考えるべきかを学びます。