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

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

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

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

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

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

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

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