テストの防御線

現在のテスト構成

Regression：過去の安全契約を、変更後も守る

回帰testは新機能の確認だけではありません。KYC、口座、Ledger、振込、逆仕訳、admin、audit、reconciliation、権限といった既存契約を、新しいOTPやお気に入り追加後も壊していないか確かめます。Hosted DBへ実dataを作るためrunnerは並列安全ではないと明記され、suiteを直列に進めます。

1. 01run-regression.mjsを開始
2. 02固定actorとfixtureの前提をassert
3. 03run.mjsがDB/RPC suiteを直列実行
4. 04run-api.mjsがHTTP API suiteを実行
5. 05全結果をDB / API / TOTALで集計
6. 06失敗したcase IDとdetailから退行箇所を特定

API test：DBが安全でも、入口が壊れることを防ぐ

API testはRoute Handler、auth context、validation、Service、error変換を確認します。DBへ直接RPCを呼ぶtestとは違い、HTTP境界で利用者に何が見えるかを守ります。

E2E：人が操作する一連の旅を確認する

Playwrightのfull-journey.spec.tsは、未認証redirect、customer login、KYC申請、admin承認、口座開設、freeze/unfreeze、customer/admin分離、logoutを実browserで確認します。振込arcは入力→DB解決済み名義の確認→demo OTP→完了→履歴を通り、残高不足では安全な日本語だけが表示されapplication shellが壊れないことを確認します。

Security / Privilege test：見えない権限表を検査する

privilege.mjsはUIを使わずPostgreSQL catalogを読み、公開関数が存在するか、PUBLIC/anon/service_roleへ不要なEXECUTEがないか、authenticatedだけへ必要権限があるかを確認します。主要tableのwhole-table privilege、column privilege、RLS有効化、Data API公開schemaも別々に検査します。

actorSeparation.mjsはactive adminへのcustomer INSERTがAC001で拒否される方向と、customerをadminへ昇格しようとするとAM006で拒否される方向を試し、失敗後にcollision rowが残らないことも確認します。

Case 1：function overload競合をtestが発見

PostgreSQLではfunction名だけでなく引数型の並びもidentityです。引数signature変更は『同じ関数の更新』とは限りません。Migrationではpg_procやPostgREST経由の旧契約も確認する必要があります。

1. 01execute_transfer()へdefault付き引数を追加
2. 02CREATE OR REPLACE FUNCTIONを実行
3. 03旧3引数版は別signatureなので残留
4. 043 named argumentsは旧版と新版の両方に一致
5. 05PostgRESTが選べずPGRST203
6. 06Regressionで全旧callが失敗して発見
7. 07旧3引数signatureを明示DROPし1候補へ戻す

旧: execute_transfer(text, bigint, uuid)
新: execute_transfer(text, bigint, uuid, text DEFAULT NULL, ... )
3引数call → 2候補 → PGRST203

Case 2：状態機械をWHERE句で消したバグ（#128以前のデモOTP実装）

DBに行は存在していても、WHERE条件で見えなくするとprogramからはnot foundに見えます。状態機械では『存在しない』『終了した』『今も有効』を別の意味として扱い、行を取得してから状態を判断します。transferOtp suiteは5回目と6回目の結果を固定します。

1. 01OTPを5回誤入力
2. 02challenge.status = failed
3. 03旧queryはWHERE status = 'active'
4. 04failed行が検索結果から消える
5. 05『存在しない』分岐へ入りotp_expired
6. 06最新challengeをstatus不問で取得
7. 07取得後にfailed / expired / superseded / consumedを分岐

Case 3：生DBエラー漏洩をE2E更新中に発見

修正では内部診断まで捨てず、private tableのfailure_reasonにはraw messageを残します。外部境界にはcodeだけを渡すことで、運用者の調査能力と利用者への情報最小化を両立しています。

1. 01OTPは正しいがexecute_transfer()が残高不足
2. 02exceptionのmessage_textをfailure_reasonへ格納
3. 03同じmessageをRPC responseへ返す
4. 04clientへ内部詳細が出る経路になる
5. 05RPC returnをfailure_code=SQLSTATEへ変更
6. 06mapRpcError()がallowlist済み日本語へ変換
7. 07E2Eでraw DB patternがbodyにないことを確認

Concurrency test：順番に2回では再現できない

同時実行testは複数sessionの処理時間を重ね、同じ古い状態を読ませます。Minibankには冪等性unique、口座row lock、決定順lock、admin caller row lockなどのDB対策と一部のmulti-session adhoc検証があります。

一方、adminQuorum suiteは真の同時disable競合を通常Regressionで実行しないと明記しています。全振込・KYC・admin操作のraceを再現する決定的なconcurrency suiteや、長時間の負荷・耐久testが完成済みとは記載しません。

安定点5173876の検証記録

今回のRegressionではHosted環境にtest外のactive admin_managerが2人存在したため、『最後のmanager』を作る前提が成立せずADMIN-005/006は安全にSKIPされました。runner集計はskipを分母から除外し、実行された280 caseがPASSです。環境依存で危険な操作を無理に行わない設計もtest harnessの重要な性質です。

実際のMinibankでは

安定点の新suiteとしてtransferOtp、transferBeneficiaries、actorSeparationがDB/RPC runnerへ組み込まれ、privilege matrixにはrequest_transfer、confirm_transfer_otp、reissue_transfer_otp、admin_list_transfer_requestsが追加されています。お気に入りsuiteはowner分離、自己口座、重複、非owner更新・削除、last_used_at、audit、table ACLを確認します。