下流テスト

ライブラリが実際にどのように使用されているかという情報は、ライブラリ自身のテストやドキュメントではなく、依存する側のコードに存在します。誰かがあなたのエラーメッセージを正規表現で解析していたり、あなたが文書化していない結果セットの反復順序に依存していたり、可視性を強制しない言語でプライベートとマークされていないため内部メソッドだと考えているメソッドに依存していたりする可能性があります。ヒュームの法則は、十分な数のユーザーがいる場合、これらの暗黙的な契約がすべて存在すると述べており、セマンティックバージョニング（semver）では対応できません。なぜならバージョン番号はメンテナーの意図を示すものであり、下流のコードが実際に依存しているものを示すものではないからです。2023 年の Maven に関する研究では、依存関係の更新の 11.58% にクライアントに影響を与える破壊的変更が含まれており、そのほぼ半分が非メジャーバージョンのアップグレードで発生していました。ほとんどのライブラリメンテナーには公開前にバージョン番号を検証する方法がないため、フィードバックループは反応的になります：リリースしてバグレポートを待ち、パッチを切る前に破壊的な影響が広範囲に及んでいないことを願うのです。 Debian パッケージは DEP-8 仕様に従ってテストスイートを宣言しており、パッケージが不安定版から安定版への移行候補となった際、移行ツール Britney はそのパッケージおよびすべての逆依存関係に対して autopkgtest をトリガーします。回帰現象は移行をブロックするため、依存先でテスト失敗を引き起こす Expat の更新は、誰かがそれを解決するまで不安定版に留まります。同様に、mathcomp-analysis や mathcomp-finmap を壊した Coq の更新も同じ扱いを受けました。変更が不安定版への参加を希望しないユーザーに到達する前に、メンテナーは誰をどのように壊したかを確認します。 Autopkgtest は API 互換性をチェックしません。それは実際の消費者の実際のテストスイートを実行し、そこにはアップストリームメンテナーが聞いたこともないような暗黙的な契約も含まれています。ライブラリ Y がパッチリリースでハッシュテーブルのソート順序を変更し、パッケージ X のテストがその順序が安定していると仮定していた場合、誰かがどちらの仮定が間違っているかを決定するまで移行はブロックされます。 Fedora は最近、tmt、Packit、Testing Farm との連携により、リリース前に PR 内で下流テストを実行する取り組みを進めています。Cockpit プロジェクトはこの仕組みを構成しており、コアライブラリへの PR を開くと、提案された変更に対して cockpit-podman やその他の依存プロジェクトのテストスイートが自動的に実行され、マージ前のステータスチェックとして結果が表示されます。彼らが述べているように、「そもそもディストリレベルでは手遅れです。その時点では、回帰を含む新しいアップストリームリリースはすでに完了しており、原因となった変更は数週間前に既に導入されている可能性が高いのです」。 メンテナが PR 内で不具合を発見した場合、まだ変更の範囲内にいます。なぜエラーパスを再構築したのかを覚えており、どのテストを検討したかも知っており、差分も目の前にあります。この時点で下流での失敗に対応するコストは、数分の思考と、おそらく修正されたアプローチで済みます。一方、同じ不具合がリリースから 3 週間後に問題として報告された場合、メンテナは変更の文脈を再読込みし、なぜ壊れたのかを理解するために下流プロジェクトの使用状況を十分に把握する必要があり、前方修正すべきかリバートすべきかを決定し、新しいリリースを作成し、すでに固定バージョンを使用している消費者がアンピン（固定解除）してくれることを願うしかありません。両方のケースで得られる情報は同じです。「下流テストに失敗した」という事実ですが、それに対応するコストは、原因となった変更からの距離に応じて増大します。 Debian の autopkgtest は、テスト環境への移行前に不具合を検出します。これは事後に検出するより優れていますが、その時点ですでに変更はアップストリームでリリース済みです。一方、Fedora のアプローチでは、アップストリームのリリース自体が発生する前に不具合を検出するため、メンテナーは自分たちの CI 環境外の誰かが遭遇する前に修正できます。František Lachman と Cristian Le は FOSDEM で PTE プロジェクトを発表しました。コード変更を執筆している最中に届くダウンストリームからのフィードバックは、その変更自体に対する考え方を根本から変えます。 言語エコシステム ディストリビューションがこれを実現できるのは、言語エコシステムに欠けている構造的な特性を持っているからです：単一の正統な依存関係グラフ、標準化されたテストインターフェース（Debian の場合は DEP-8）、すべてのパッケージが同じ方法でビルドされ実行される共有実行環境、そしてダウンストリームの結果に基づいてリリースをブロックする権限です。npm、PyPI、RubyGems はツールが断片化しており、リポジトリ外からパッケージのテストを呼び出す標準的な方法がなく、実行環境も多様であり、メンテナー自身の判断以外の何かに基づいて公開を制限する仕組みを持っていません。一部の言語エコシステムではダウンストリームテストの部分的な実装が進んでいますが、これらは通常、これらのギャップを埋めるリソースを持つコンパイラチームに属しています。 Rust の crater は、crates.io 上のすべてのクレートを現在のコンパイラと提案中のコンパイラの両方でコンパイル・テストし、結果を差分比較します。最近の PR で f32 に対する impl From が追加されました Crater は Rust がコンパイルされる点からも恩恵を受けています。型推論の失敗は、テストを実行する前のビルド時点で検出されます。一方、Python、Ruby、JavaScript では、同様の不具合が表面化するのはランタイム時であり、そのため影響を受けるコードパスを実際に実行するダウンストリームテストスイートが必要となります。さらに、それらのコードパス自体が最初にカバされている必要があります。コンパイルステップが存在せず、簡単なミスを検出できないため、動的なエコシステムではダウンストリームテストの必要性はより強く、シグナルを取得することも困難になります。 Node.js は CITGM（Canary in the Goldmine）を実行しており、提案された Node のバージョンに対して約 80 の厳選された npm パッケージをテストします。Node 12 でのリファクタリングにより isFile メソッドが Stats.prototype から StatsBase.prototype へ移動しました。 これらすべては、専用のインフラストラクチャ予算とリリースプロセスを持つチームによって構築されました。一方、npm や PyPI、RubyGems で広く使用されるパッケージを公開する個々のライブラリメンテナーには、同等の体制はありません。彼らは異なる規模で同じ問題に直面しているにもかかわらずです。 マージ自信度 Renovate の Merge Confidence は、数百万件の更新 PR からデータを集約し、消費者に対して更新が安全かどうかを伝えます：リリースの古さ、Renovate ユーザーのうちどれほどがそれを採用しているか、そして更新結果としてテストに合格する割合などです。このシグナルは実際のプロジェクトにおける実際のテスト結果から得られますが、リリース後に消費者へ流れ、変更を公開したメンテナには決して戻りません。アルゴリズムは非公開であり、どの更新がどのプロジェクトのテストを壊したかという基盤となるデータセットも、Mend の有料壁の向こう側に残されています。 Dependabot はセキュリティ更新 PR に対して互換性スコアを表示しますが、これは同じ更新を行った他のパブリックリポジトリの CI 結果から計算されます。ただし、少なくとも 5 つの候補更新が存在する場合に限られ、データもメンテナへは戻りません。私はこのシグナルのオープン版を構築するために、dependabot.ecosyste.ms で Dependabot の PR をインデックス化し始めました。まだ CI データはありませんが、すでに更新ごとのマージ率を追跡しており、これは特定のバージョンアップがエコシステム全体でどの程度のトラブルを引き起こしているかの大まかな代理指標となっています。 レジストリは、他のパッケージに依存関係を宣言するパッケージを追跡しますが、ライブラリを消費するアプリケーションはほとんど可視化されません。gem に依存する Rails アプリケーションは RubyGems の逆依存関係リストには表示されず、npm パッケージを使用する企業の内部サービスも npmjs.com 上には現れません。依存先に関するメンテナの視点も、レジストリが把握できる範囲に限られており、これは他のライブラリに大きく偏っており、アプリケーションを見逃しています。しかし、ここでこそ、奇妙な使用パターンやより驚くべき暗黙的な契約が現れる場所なのです。 ecosyste.ms は、パッケージとオープンソースリポジトリの両方にわたって依存先を追跡し、GitHub、GitLab、およびその他のフォージ上の数百万のリポジトリをスキャンして、依存関係を宣言するマニフェストファイルを探します。メンテナは、実際に自分のライブラリを使用しているアプリケーションを確認できますが、これは下流テストシステムを構築するために必要な視点です。 これは ecosyste.ms の上に構築したい機能です。メンテナーが CI サービスに接続すると、すべてのプルリクエストやプレリリースブランチにおいて、ecosyste.ms に対してそのパッケージの上位 N 件の依存先（ライブラリとアプリケーションの両方）を照会します。ランク付けは、依存先の数、ダウンロード量、コミットの最新性の組み合わせに基づいて行われます。その後、各依存先をクローンし、現在のリリース版の代わりに提案されたバージョンのライブラリを置き換えた上で、隔離環境内でテストスイートを実行します。結果はプルリクエストへのレポートとして返されます：どの依存先がテストされたか、どの依存先で後退（レグレス）が発生したか、スタックトレースの内容はどのようなものか、メンテナーの変更のうち各失敗の原因となった可能性が高いものはどれか。 リリースタグを付ける前にこのレポートを確認するメンテナーには、現在では自分たちには見えない事象が明らかになります。例えば、人気のあるアプリケーションがエラーメッセージを正規表現でパースしており、文言が変わると壊れてしまうこと、広く使われているラッパーライブラリが内部とみなしていたメソッドを呼び出しており、それが削除されようとしていたこと、データベース呼び出しのバッチ処理に関する最適化によりコールバック順序が変更され、それが 2 つの下游プロジェクトの統合テストに依存していることがわかります。 Michal Gorny が指摘する下流テストにおける Python パッケージの問題カタログは、以下の失敗モードを列挙しています。インストール済みファイルを破棄可能なコンテナ内にあると仮定して変更を試みるテストスイート、環境内の pytest プラグインが予期せぬテスト収集を引き起こす問題、ネットワークアクセスや Docker を必要とするテスト、アーキテクチャ間で異なる浮動小数点精度の差異、テストファイル自体を省略したソースディストリビューションです。レジストリー全体でこれを実行しようとするサービスは、これらのすべてを適切に処理し、本格的な回帰と環境ノイズを区別する必要がありますが、これは Debian が autopkgtest を用いて何年もかけて改良してきたにもかかわらず、まだ完全に解決できていない難しい問題です。 ecosyste.ms はすでに依存関係の発見を提供しており、ソースリポジトリはパッケージメタデータからリンクされています。テストスイートは自動化可能なほど十分に理解されているエコシステム規約に従っており、コンテナインフラストラクチャにより隔離環境を低コストで実現できます。Crater と autopkgtest は、このアプローチがエコシステム規模で機能することを証明しています。

下流テスト

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト