「確かめたつもり」をなくす。第3世代の限界

手で動かして確かめたスクリプトが、定時実行では動かない。自分の環境では、原因の多くが権限でした。

macOS では、書類フォルダや Downloads、クラウドの同期フォルダを読むのに、アプリごとの許可（フルディスクアクセス^※1など）が要ります。ターミナルから手で動かすと、ターミナルの許可で読めます。launchd^※2 から動かすと、その許可は使えません。読めないとエラーにならずに「0件」として進むことがあり、自分の環境では、画像の振り分けジョブが「0件・成功」を57回続けていました。

だから、新しいジョブや直したジョブは、本番と同じ呼ばれ方で1回動かしてから完了にします。手で動かして通っただけでは、確かめたことになりません。

テストのつもりで動かした処理が、本物の記録を書き換えていた、ということも起きました。自分の環境のテストは、本番のロックファイル、本番の鍵のファイル、本番のログに触れていて、212件中14件が失敗したままになっていました。テストが書いた警告は本番のログに混ざり、見張りの仕組みが誤った警報を出していました。

防ぎ方は、本物の置き場所（ロック、ログ、状態のファイル、鍵）を、モジュールの先頭の差し替えられる1か所にまとめ、テストではそこを一時フォルダに差し替えることです。関数の中でパスを組み立てていると、差し替えられません。

「試しに動かすだけ（dry-run^※3）」の実行が、成功の記録を書いてしまう、ということもありました。壊れているジョブを調べるために試し実行をしたら、その実行が「成功」を記録して、壊れている証拠を上書きしてしまったのです。

試し実行は、送り先のフォルダも作らない、記録も書かない、が原則です。自分のバックアップのジョブは、試し実行でも送り先のフォルダを作ってしまう作りだったので、直しました。試し実行が本物に何も書かないことを、テストで確かめておくと安心です。

情報を取り出すだけに見えるコマンドが、実はファイルを書き換える、ということがあります。自分は、macOS の設定ファイルから値を取り出す plutil -extract を調べもののために何十件にもかけて、51件の設定ファイルを壊しました。出力先を指定しないと、取り出した値で原本を上書きするコマンドだったのです。

初めて使うコマンドや、たくさんのファイルにまとめてかけるコマンドは、まずコピーした1件で試し、原本が変わっていないことを確かめてから本物に使います。AIに頼むときも、「コピーで試して、変わっていないことを確かめてから」と書きます。

検査がいつも「合格」を返していたら、検査が壊れている可能性があります。わざと失敗するはずの入力を1つ入れて、ちゃんと落ちるかを確かめます。落ちない検査は、無いのと同じです。

この考え方を広げたものに、ミューテーションテスト^※4があります。コードをわざと少し壊して（条件を逆にする、数字を変えるなど）、テストがそれを見つけられるかを調べるやり方です。全部を自動でやらなくても、「大事な検査に、わざと壊した入力を1つ流す」だけで、かなりのことがわかります。

1回の作業なら、ここまでで十分に安全にできます。残るのは、人がその場にいないと始まらないことです。夜中や休みの日にも回したくなったら、次の段（ループ）が必要になります。

そして、ループに進むと、ここで見た4つのずれは、もっと見つけにくくなります。人がその場で結果を見ないからです。だからこの回の確かめ方は、ループを作る前に身につけておきたいものです。