ソフトウェアテストを書く時の心得

AIは放っておくと、無限に正常系のtestを書き、アクセス権限の境界のtestが下手である。以下の基準は、きりが無い正常系のtestをやめ、情報漏洩を避ける為にクリティカルな境界条件を見つけてそこをtestする為の物である。testを書く時、足すかどうかを決める時、落ちたtestを直す時、test runnerを移行する時、レビューする時に従う。

心得1. 守りたいラインを決めて、そこだけに最小限書く

testは、そのPRが正しい事の証明であると同時に、別の変更によって壊されないように守る物である。守りたいラインを決めて、将来壊れるだろう場所を予測して、そこだけに最小限書く。ラインを決めずに書くと、仕様変更の度にtestの大半を書き直す事になり、その作業でミスが入って情報が漏洩するので、testが実質的に何も守ってくれない状態になる。

• 「別の機能追加によって壊されるかも」と思った箇所に重点的に仕込む。別ファイルの関数を1つだけimportして使っている、ファイルの読み込み順や関数の登録順に依存している、依存ライブラリを更新した、ライブラリ同士の食い合わせが悪い、といった経路で、無関係だと思っていた機能同士が実はどこかで関係している
• 壊れても問題ない部分には書かない

心得2. 情報が漏洩していないかを重点的にtestする

memberであればアクセスできる事ではなく、memberではない人がアクセス拒否される事をtestする。test書きすぎを防ぐ為にtest対象を削る時も、正常にアクセス拒否できる事、つまり情報漏洩防止のtestは書く。

権限がある人がアクセスできない不具合は、その人が「見れないんですけど」と報告してくれる。権限が無い人がアクセスできてしまう不具合は、その多くが報告されない。自分には権限があって正常に見えているだけだと思っているか、報告が面倒か、他人の非公開情報が見えても自分に実害が無い事も多い。クリティカルな実害が発生してからようやく報告が来て、謝罪プレスリリースを出す事になる。

• 権限を厳しくする変更では、制限したい相手が実際に拒否される事をtestする。権限を緩める変更で、変更前のコードでも通り、bug修正でもないtestは、指示されない限り足さない。それでも足した方がよいと判断した時は、足す前に判断を仰ぐ。緩めた結果、残すべき制限まで外れていないかは、レビューで確かめる
• 必要なラインギリギリを見極めて、その危険側を集中的にtestする。アクセス権限の境界は1つではない。project memberだけが読めるページなら、守りたいのはmemberである・ないの境界で、ログインしているがmemberではない人にアクセスさせて403が返る事をtestする。ログインしていない人で試すのは間違いで、ログインしている・していないという別の境界をtestした事になる
• 期待するstatus codeは厳密に見る。403を期待する所で404が返ったら、落ちるようにtestを書く
• 権限がある人に200が返る事のtestだけでは、権限が無い人にも200が返っているかもしれないので、ほとんど何も守れない。今後もメンテナンスをし続ける余裕と、testの実行時間の余裕があるなら、書いてよい
• 全組み合わせを網羅せず、権限の境界の最小セットだけ書く。誰でも読めるpublic projectの読み取りなら、最も権限が低い人が通る1件で足りる
• 実装側は逆に、権限がある事を確認する。権限の種類は将来必ず増え、権限がある事を確認する実装なら、増えた権限の人にはデータが返らないので安全側に倒れる

心得3. データ形式のtestとアクセス権限のtestは分けて書く

• アクセス権限のtestは、controllerにリクエストして、拒否される事を期待するstatus codeで確かめる。pathとユーザーの種別と期待するstatus codeの組み合わせの表として書くと、一気に確かめられる。メンテが大変でなければ、境界ギリギリ以外も充実させてよい。一覧や検索のように、含まれる物で権限が決まるAPIでは、含まれてはいけない物が含まれない事を見る
• データ形式のtestは、methodの返り値を見る。単純なAPIならまとめてtestしてよい
• 超重要ではない機能で、レスポンスにfieldが存在するか確認する類のtestは書かない。書き始めるときりが無い。使っていれば分かる程度の不整合は、見つけ次第直せばよい

心得4. 実装の写しになるtestを書かない

正常系のtestを無限に足すと、実装のただのコピーになる。実装を変える時に二重に書き換える事になり、変更コストを上げるだけで何も守らない。testを足す前に、実装の量と釣り合っているか、bugがあった時に何が起きるかを考える。bugの帰結が情報漏洩や権限の逸脱のような危険側なら、その異常を検知するtestを検討する。表示が減る・処理が呼ばれないだけで実害が無い安全側なら書かない。次のtestは、安全側で実装の写しになる物なら書かない。

• 定数配列や、arr.map(fn) のようにロジックの無い薄いラッパーの単体test
• fixtureを整形関数に渡して、出力の部分文字列を確かめるtest
• schema validatorを直した時に、validatorが正しく書けている事を確かめるだけのtest
• 処理の呼び出しを消しただけの修正で、消した処理が実行されない事を確かめるtest
• bug修正で、直した事を確かめる為の「念の為の回帰防止」の正常系test。「将来誰かが再導入したら検出できる」は弱い動機で、確認は手元の実行で済ませる

心得5. fixtureの仮名には、ユーザー自身のhandleを使う

test fixtureや設定の例で仮のメールアドレスやユーザー名を書く時、局所部には、作業を指示しているユーザー自身のhandleを使う。taro のような汎用的な人名は、実在の人物のアカウントと同じになると問題になる。自分のhandleなら、実在しても本人である。ドメインは .example か、既存のtestに合わせる。

心得6. testを通す事だけを目的に、実装やtestの機構に手を加えない

testが落ちた時に、testを通す事だけを目的に、実装のほうを直したり、testの根本的な方針や機構に手を加えたりしない。

心得7. test runnerを移行する時は、testの合計件数を確かめる

移行の前後で、実行されるtestの合計件数が変わらない事を確かめる。