基本の14章 · 11

「確かめた」を、証拠の大きさに合わせる

ソース、単体テスト、データベース、実認証、画面。その違いを見分ける。

本文の説明・図・掲載コードだけで読み進められます。出典リンクは、権限のある人向け(非公開GitHub)です。GitHubで閲覧権限がある方だけ開けます。

この記事でわかること

  • 仕様が書いてある証拠と、実際に動いた証拠は違う
  • 拒否後に何も変わっていないことまで確認する
  • 検証の時点・環境・前提を結果と一緒に残す
この記事の目次
01 / READ THE SYSTEM

一枚の成功画面から、何が言えるか

架空のレビュー会で「送金完了の画面が出ました」と報告されたとします。分かるのは、その画面が表示されたことです。実際の Auth でログインしたか、送金が一件だけ記帳されたか、他人の口座では拒否されるかまでは、その画像だけでは分かりません。検証とは、欲しい結論に必要な証拠をそろえる作業です。

MiniBank の資料では、固定データを使った表示確認、簡易セッションでの通し確認、実 Auth を使う確認が分けられています。同じ「ブラウザを使った」という言葉でも、証明できる範囲は違います。読み手は結果の大きさより、どの前提で何を確かめたのかを見ると、過大な安心と不必要な疑いの両方を避けられます。

根拠:ローカル受け入れの記録(非公開GitHub・要権限)

02 / READ THE SYSTEM

下から積む検証は、互いの代用品ではない

型検査は、データの形の食い違いを探します。単体テストは、小さな計算や状態判断へ決めた入力を渡します。DB テストは、実際の表や関数で、残高・仕訳・権限・競合を扱います。画面の通し確認は、入力から結果表示まで人が通る道を確かめます。それぞれ見つけやすい失敗が異なります。

通常 CI の定義には型検査、lint、build があります。この CI が成功しても、定義にない銀行 DB の全試験や実認証を実行したことにはなりません。逆に、DB の試験が成功しても、入力欄に名前がなく読み上げられない問題は残り得ます。検証を一個の緑色へ縮めず、層ごとの証拠を残すことが設計の一部です。

1ソース・型契約とデータの形
2DB・権限確定結果と拒否
3API・実 Auth接続と本人の境界
4画面・人操作と理解のしやすさ

表示の検査でも、何を測るかで結果は変わります。入力欄の隣に「金額」と書いてあることと、支援技術がその欄の名前を金額として読めることは別です。受け入れ記録では、ラベルが入力欄へ結び付いていない不備を見つけ、結び付きを検査する再発防止も追加しています。タブキーが進むこと、停止位置に見える枠があること、操作要素に名前があることは自動で観察できますが、読み上げの順序や説明の分かりやすさは、それだけでは判断できません。画面幅を変えて横にはみ出さないことを確かめる試験も、取引の正しさとは別の価値を持ちます。見た目、操作、理解、金融状態を別々の観測項目にすると、どれか一つの成功へ依存せずに利用者の体験を検証できます。

根拠:通常 CI の定義(非公開GitHub・要権限)

根拠:ローカル受け入れの記録(非公開GitHub・要権限)

03 / READ THE SYSTEM

成功させるより、止まり方を確かめる

山田さんが他人の依頼 ID を送ったとき、エラーになることは必要です。しかし、エラーの前に残高だけが変わっていたら安全ではありません。そこで負のテストでは、拒否を受けたことと、送金件数・仕訳・残高などが前後で変わらないことを組み合わせます。金融システムでは「失敗しました」という返事だけでは不足します。

同じ操作を二度送る、二人が同時に承認する、待っている間に権限を失う、口座が凍結される、といった境界も重要です。毎回別のキーで成功を一度確かめるだけでは、再送や競合の欠陥は見つかりません。停止境界のテストは、止めるべき変更と診断のために残す記録を分けて扱います。

テストを読む:エラーの外側も観察する

これは実行用ではない、検証観点の擬似コードです。

変更前の残高・仕訳件数・依頼状態を保存する
権限のない操作者で操作を試す
拒否された理由を確認する
変更後の値を読む
金融状態が変わらないことを比べる
必要な失敗監査だけが残ることを確認する

根拠:停止境界のテストソース(非公開GitHub・要権限)

04 / READ THE SYSTEM

使い捨てデータにも、壊し方の責任がある

試験用の利用者や口座を fixture と呼びます。便利な脇役に見えますが、片付けの順序を誤れば、試験が本来の状態を壊します。十月三日の修復記録は、古い通知試験の後片付けが、空の元帳を消した後に口座削除で止まり、欠損を残した経路を説明しています。残高がゼロでも、関係する記録がないとは限りません。

その記録では、条件を厳密に満たす試験用の欠損だけを対象とし、既存の取引や過去残高を作り直さず、正規の空元帳を追加する修復を検証しています。片付け自体も一つのトランザクションへ直しています。学べるのは「テスト用だから自由に消してよい」ではなく、準備と終了も業務の不変条件を守る必要があるということです。

根拠:2026年10月3日の修復 RC 記録(非公開GitHub・要権限)

05 / READ THE SYSTEM

数字には日付と環境を付ける

v20 の受け入れ記録には、三十八画面と五つの業務の流れを隔離環境で通した結果があります。ただし、そこで使った簡易セッションは実 Auth や TOTP の証拠ではなく、手動のスクリーンリーダー確認でもありません。種データの条件で融資の申込画面が出ないという前提も追記されています。成功数だけを抜き出すと、この条件が消えてしまいます。

また、後日の修復で migration が追加され、検証件数も更新されています。古い一覧の件数を最新の完了証拠として転記してはいけません。本教材では、資料に残った過去の結果と、今回の読み物の検証を分けます。銀行テストや本番の取引を実行していないため、新しい銀行動作の PASS は付けません。

根拠:ローカル受け入れの記録(非公開GitHub・要権限)

根拠:2026年10月3日の修復 RC 記録(非公開GitHub・要権限)

06 / READ THE SYSTEM

未検証を、次に必要な証拠へ変える

「実認証は未確認」という記録は、全機能が壊れている意味ではありません。一方で、「ローカルで全部通ったから実認証も大丈夫」と埋めることもできません。どの利用者、どの接続先、どの操作、どの結果を確認すれば閉じるかを明確にすると、未検証は次の作業を選ぶ材料になります。

検証結果の良い書き方は、対象 commit、環境、入力、観測した結果、残る制約を一組にすることです。失敗を見つけたら、期待値を都合よく変える前に仕様と照合します。意図的に防御を壊してテストが失敗するかを見る変異テストも、検出力を調べる方法です。ただし、その一部の再実行を全体の再実行と呼ばない慎重さが最後まで必要です。

根拠:v20 停止と監査の記録(非公開GitHub・要権限)

SOURCE NOTES

出典と、確認できた範囲

コードの説明と、稼働環境の検証を分けます

以下のリンクは非公開GitHubへの出典で、閲覧権限が必要です。本文はリンク先を開かなくても読める構成です。固定コード・設計資料を参照していますが、今回、この読み物のために銀行の取引やDB操作、本番試験は実行していません。実装や資料にある検査と、こちらで実施した検証を混同しないようにしています。

  1. ローカル受け入れの記録 ↗(非公開GitHub・要権限)
    簡易セッションの画面検証と未検証範囲の区別
  2. 通常 CI の定義 ↗(非公開GitHub・要権限)
    型検査・lint・build が行う範囲
  3. 停止境界のテストソース ↗(非公開GitHub・要権限)
    拒否結果だけでなく更新の不変を検査する仕様
  4. 2026年10月3日の修復 RC 記録 ↗(非公開GitHub・要権限)
    追加修復と最新記録時点の検証・未実施の範囲
  5. v20 停止と監査の記録 ↗(非公開GitHub・要権限)
    修正履歴・検証範囲・受容した限界

MiniBankは学習・検証用の銀行アプリです。架空の金額や人物は、仕組みを説明するための例です。

つながる読み物

ここまで読んだ記録を、ひとつ。

自分のペースで。あとから取り消すこともできます。

次の読み物公開は、コードを置く前から始まる
→