OSSプロジェクトの統合テスト-認証でサードパーティを処理する方法？

私の（オープンソースの）趣味プロジェクトの1つは、GitHub、Bitbucketなどからリポジトリのオフラインバックアップを作成するバックアップツールです。
ホスティング事業者のAPIを呼び出してリポジトリのリストを取得し、Git / Mercurial /何でもクローン/リポジトリをローカルコンピュータにプルします。

したがって、認証を使用してGitHub APIを呼び出す統合テストがあります。
（そして、クローン/プル機能が終了すると、おそらくGitHubからリポジトリをクローンするテストがあり、認証も必要になります）

特にこれらの統合テストで使用するユーザーと組織を作成しました。

問題：オープンソースであり、コードがGitHubで公開されているため、ソースコードのどこかにパスワードをハードコードすることはできません。

私が今やっていること

テストでは、環境変数からすべてのユーザー名、パスワード、リポジトリ名を取得しています。
次に例を示します。

config.Name = TestHelper.EnvVar("GithubApiTests_Name");
config.Password = TestHelper.EnvVar("GithubApiTests_PW");

（TestHelper.EnvVar環境変数の値を取得し、存在しない場合は例外をスローするヘルパーメソッドです）

次に、これらの環境変数を設定するバッチファイルがあります。
実際のenvironment-variables.batスクリプト（）は、ビルドスクリプトでテストを実行する前に呼び出されますが、ソース管理では無視されるため、実際にはリポジトリにありません。

何でソースコントロールであるでenvironment-variables.bat.sampleはなく、偽のパスワードで、同じ環境変数を設定し、：

rem copy/rename this file to environment-variables.bat

echo Setting environment variables for integration tests...

set GithubApiTests_Name=scm-backup-testuser
set GithubApiTests_OrgName=scm-backup-testorg
set GithubApiTests_PW=not-the-real-password
set GithubApiTests_Repo=scm-backup

リポジトリを自分のマシンに複製し、このファイルの名前をに変更しenvironment-variables.bat、偽のパスワードを実際のパスワードに置き換えると、すべての統合テストが機能します。

これは継続的インテグレーションでも機能します。私はAppVeyorを使用しており、Web UIでこれらの環境変数を設定できます。

それについて私が嫌いなこと

私はそれがOSSプロジェクトにとって、特にこのプロジェクトにとっては良い解決策ではないと思います：

理論的には、私のプロジェクトの貢献者は、次の方法で統合テストをすぐに実行できます。

GitHubで自分のテストユーザーとテスト組織を作成する
テストリポジトリの作成
environment-variables.bat異なる値を持つ彼自身のバージョンを作成する

問題は、私のアプリケーションが複数のソースコードホスターをバックアップできることです。
現在のところ、GitHubのみをサポートしていますが、適切なインターフェースを実装するクラスをいくつか追加することで、より多くのホスティングサービスを簡単に追加できます。

したがって、後でより多くのホスティング事業者のサポートを実装すると、環境変数の数が増えます。すべての統合テスト
を実行できるようにするには、潜在的な貢献者がGitHub、Bitbucket、GitLabなどで独自のユーザー、組織、テストリポジトリを作成し、さらにいくつ知っているかを確認して、すべてを自分のバージョンに追加します。 environment-variables.bat

コードが公開されているプロジェクトでこれを行う方法のより良い解決策はありますか？

他のプロジェクトが、私が現在やっていることと同じようなことをしていることを知っています。
たとえばOctokit.netには、GitHub APIを呼び出す統合テストの環境変数を設定するスクリプトがあります。
しかし、必要なのは1人のユーザーと1つの組織だけであり、さらに多くのものが必要になります。

多分私は貢献者が実際にすべての統合テストを実行することを可能にするソリューションを必要としません。
たとえば、誰かが私のプロジェクトのGitHubサポートに貢献したい場合、GitHub統合テストを実行できれば十分です。
統合テストを無数の「グループ」（？）に分割し、「グループ 'Github'に属するすべてのテストを実行する」という適切な方法が必要かもしれません。

— クリスチャン・スペクト
ソース

現在の設定で問題ないと思いますが、いくつか調整を行います。

すべての統合テストを実行できるようにするには、潜在的なコントリビューターがGitHub、Bitbucket、GitLabなどで独自のユーザー、組織、テストリポジトリを作成し、さらに詳しい情報を知っている人がすべてを自分の環境変数に追加します。 .batバージョン。

はい、そうですが、コントリビューターはプロジェクトにPRを作成する前に、必ずしもすべての統合テストを実行する必要はありません。PRが作成されると、CIは完全なテストスイートを実行します。

どういうわけか簡単に実行できないテストスイートがあるのが一般的です。多くの組織では、実行に数日かかるテストスイートを維持しています。そのため、開発者は実行が容易なテストを選択的に実行し、より厳密なテストのためにコードを進める必要があります。私は同じアプローチを提案しています。

通常の/信頼できるコントリビューターの場合、プロジェクトの実際のコントリビューターにして、PRを作成する前にブランチでCIを実行できるようにすることができます。

とは言っても、貢献者が完全なテストスイートを実行することを妨げるものではありません。彼らは独自のGitHub資格情報を提供したり、独自のテストアカウントを作成したりできます。通常の寄稿者がこれを行う可能性があります。

私が提案する調整は次のとおりです。

まず、ほとんどのテストカバレッジユニットテストを作成します。これらは、コードベースのすべてのブランチをカバーする必要があります。

次に、エンドポイントがモックされる統合テストを記述します。これらのAPIのトランスポート層をモックして、偽のGitHub Restサービスを開始することで、HTTP要求/応答フローをシミュレートすることもできます。例（擬似コード）：

// Test failed authentication to GitHub
val server = new WebServer("localhost", 9453, { request =>
    return Response(401, "unauthenticated")
})
server.start()
val backupService = new GitHubBackupService("http://localhost:9453")
backupService.backup must throw UnauthenticatedException()
server.stop()

これらのテストはより複雑になりますが、

偽のアカウントとリポジトリを作成せずにテストする
実際のGitHubでシミュレートするのが難しいであろう障害状態をテストします。たとえば、502応答、接続タイムアウト、異常な/解析不可能な応答本文。

3番目に、特別な知識が必要なテストを、通常のビルドで実行しないようにします。ほとんどのビルド管理ツールには、統合テストまたはタグテストを分離して選択的に実行する方法があります。コントリビューターは、事前の構成なしでソフトウェアをビルドおよびテストできる必要があります。完全なテストスイートは、CIでビルドするたびに実行する必要があります。

最後に、テストとその実行方法をテストドキュメントに文書化して、貢献者がテストを実行できるようにします。

— サミュエル
ソース