如何用 make testacc 运行单个后端的验收测试TEST 与 TESTARGS 参数及真实资源风险说明【免费下载链接】vaultA tool for secrets management, encryption as a service, and privileged access management项目地址: https://gitcode.com/GitHub_Trending/va/vault假设你正在改 Vault 的某个 secret/auth method 或存储后端physical backend需要针对这一个后端跑验收测试来确认功能可用、且没有破坏其他行为。README 建议在这种情况下运行验收测试acceptance tests而执行入口就是make testacc TEST后端目录。跑通之后你会得到该后端验收测试的完整-v输出并且事先知道测试会创建哪些真实资源。testacc 目标实际执行了什么Makefile 中testacc目标的完整逻辑是# testacc runs acceptance tests testacc: BUILD_TAGStestonly testacc: prep if [ $(TEST) ./... ]; then \ echo ERROR: Set TEST to a specific package; \ exit 1; \ fi VAULT_ACC1 $(GO_CMD) test -tags$(BUILD_TAGS) $(TEST) -v $(TESTARGS) -timeout$(EXTENDED_TEST_TIMEOUT)可以从中读出四个关键行为它先依赖prep即会执行go generateMakefile 注明生成文件通常已提交到 git了解这一点时可以设SKIP_GEN1跳过prep还包含check-go-version按 Makefile 第 24 行的GO_VERSION_MIN$$(cat $(CURDIR)/.go-version)校验本机 Go 版本。如果TEST恰好是字面量./...直接报错ERROR: Set TEST to a specific package并以退出码 1 结束——这是 Makefile 强制你指定具体包的机制。运行时注入环境变量VAULT_ACC1。这正是验收测试与单元测试的区别test目标会显式清空VAULT_ACC再跑单元测试而各后端的验收测试代码会在VAULT_ACC为空时直接t.Skip()见 physical/s3/s3_test.go 中DoS3BackendTest开头的判断。最终命令形如go test -tagstestonly TEST -v TESTARGS -timeout60m其中 60 分钟来自 Makefile 中的EXTENDED_TEST_TIMEOUT60m。TEST 参数指定到单个后端的目录README.md 的 “Acceptance Tests” 一节明确TEST变量是必需的required应指定后端所在的目录并给出的示例命令是$ make testacc TEST./builtin/logical/consul对 physical 存储后端同理包路径即目录路径例如make testacc TEST./physical/s3 make testacc TEST./physical/gcs一个容易踩的坑Makefile 第 9 行把TEST默认定义为除integ/外的全部包列表TEST$$(echo $(ALL_PACKAGES) | grep -v integ/ )。这意味着如果不显式传TEST它不会触发上面的./...拦截而是把VAULT_ACC1的验收测试铺到所有包上执行——在真实资源风险见下文存在的前提下务必始终显式传入单个后端目录。TESTARGS 参数把范围缩小到具体测试README 对TESTARGS的说明是推荐用它把范围过滤到某个具体测试因为一次跑完全部用例“有时可能非常慢”。从testacc目标可以看到TESTARGS会原样拼进go test命令行因此可以直接传go test的标准过滤参数。physical/s3/s3_test.go 中定义的测试函数有TestDefaultS3Backend和TestS3BackendSseKms后者走 KMS 加密的 S3 后端例如只跑 KMS 那个make testacc TEST./physical/s3 TESTARGS-run TestS3BackendSseKms如果后端用例不多也可以不传TESTARGS让该包内全部测试执行——命令里-v保证每个用例都有单独输出。后端所需的环境变量由测试自己提前报错提示README 的说明是验收测试通常还需要设置其他环境变量例如访问密钥具体设什么不在此文档中列举测试本身会尽早报错并告诉你要设置什么。实际代码中的表现与这一致举两个可核对的例子S3 后端physical/s3/s3_test.go先检查VAULT_ACC为空则跳过再检查 AWS 凭据解析不到时跳过并提示Skipping because AWS credentials could not be resolved.提示信息中附带 AWS SDK 凭据配置的官方文档链接。区域取AWS_REGION或AWS_DEFAULT_REGION都未设时回落到us-east-1。此外支持AWS_S3_ENDPOINT指定 S3 兼容端点——注释要求是含 scheme 的完整 URL例如http://127.0.0.1:9000不设置则使用 AWS 默认端点可用于指向 MinIO 之类的自建服务从而避免直接消耗 AWS 真实资源。GCS 后端physical/gcs/gcs_test.goTestBackend要求设置GOOGLE_PROJECT_ID未设置时t.Skip(GOOGLE_PROJECT_ID not set)。所以执行路径是先不带凭据跑一次读输出里 SKIP/错误信息告诉你缺哪个变量补齐后再跑。真实资源风险跑之前必须知道的事README 对验收测试给出了明确警告这些测试会创建/销毁/修改真实资源在某些情况下可能产生真实费用若代码存在 bug损坏的后端有可能留下悬空数据dangling data。因此官方建议在自己承担风险的前提下运行并且“至少应该在为你所测后端准备的一个独立私有账户里运行”。结合测试代码可以看到风险的具体形态S3 测试会创建名为vault-s3-testacc-随机整数的 bucketGCS 测试会创建名为vault-gcs-testacc-随机整数的 bucket并在defer中尝试删除它。也就是说即使测试正常结束会尽力清理中途中断或失败仍可能留下未清理的 bucket。想降低真实成本时文档中给出的可选分支是对 S3 后端通过AWS_S3_ENDPOINT指向自建 S3 兼容端点如 MinIO运行而不直接打 AWS。如何判断测试通过了命令固定带-v输出中每个测试函数都有独立的--- PASS/--- FAIL/--- SKIP行被跳过的用例会显示上面提到的跳过原因如凭据未解析、GOOGLE_PROJECT_ID not set这本身也是诊断信息。若用例真实运行go test在存在失败时返回非零退出码make会随之失败全部通过则正常返回 0。注意超时上限是 60 分钟Makefile 的EXTENDED_TEST_TIMEOUTREADME 同时提示全部用例一次跑完可能非常耗时这也是建议用TESTARGS过滤的原因。Windows 上的可选分支make.bat 提供同一套目标的 Windows 版本testacc行为基本一致若TEST为./...或.\...会报ERROR: Set %%TEST%% to a specific package.并退出运行时设置VAULT_ACC1但超时为45m而非 Makefile 的60m。其testsetup子例程还会先执行go generate并在未定义TEST时将其默认为./...——因此同样建议始终显式指定后端目录。【免费下载链接】vaultA tool for secrets management, encryption as a service, and privileged access management项目地址: https://gitcode.com/GitHub_Trending/va/vault创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
