OSS项目中的集成测试-如何处理带有身份验证的第三方？

我的一个开源项目是一个备份工具，该工具可从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的集成测试。
但是他们只需要一个用户和一个组织，而我将需要更多。

也许我不需要使贡献者能够实际运行所有集成测试的解决方案。
例如，如果某人想为我的项目的GitHub支持做出贡献，那么他只需要能够运行GitHub集成测试。
因此，也许我只需要一种明智的方法就可以将集成测试划分为无数个“组”（？），然后说“现在执行所有属于'Github'组的测试”。

— 克里斯汀·斯佩克特
source

我认为您当前的设置还可以，但是我会做一些调整。

为了能够执行所有集成测试，潜在的贡献者可以在GitHub，Bitbucket，GitLab等...上创建自己的用户，组织和测试存储库，并且他们知道多少，并将所有这些添加到他的环境变量中.bat版本。

是的，的确如此，但是在您的项目上创建PR之前，贡献者不一定必须运行所有集成测试。创建PR后，配置项将运行全套测试。

通常有一个测试套件无法以某种方式轻松运行。对于许多组织而言，他们维护的测试套件需要花费几天的时间才能运行，因此开发人员必须有选择地运行易于运行的测试，并将代码推向更严格的测试。我建议采用相同的方法。

对于常规/受信任的贡献者，您可以使他们成为您项目中的实际贡献者，这应允许他们在进行PR 之前在其分支机构上运行CI 。

就是说，您并没有阻止贡献者运行全套测试。他们可以提供自己的GitHub凭据或创建自己的测试帐户，常规贡献者可能会这样做。

我建议进行以下调整：

首先，进行大多数测试覆盖率单元测试。这些应该覆盖您的代码库的所有分支。

其次，编写模拟端点的集成测试。您甚至可以通过启动伪造的GitHub Rest服务来模拟这些API的传输层并模拟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响应，连接超时，异常/不可解析的响应主体。

第三，禁用任何需要特殊知识的测试，以使其无法在正常版本下运行。在大多数构建管理工具中，都有一种方法可以分离集成测试或标记测试并有选择地运行它们。贡献者应该能够在没有任何事先配置的情况下构建和测试软件。完整的测试套件应在CI中的每次构建后运行。

最后，在测试文档中记录测试以及如何运行它们，以便贡献者可以选择运行它们。

— 塞缪尔
source