测试开发工具【免费下载链接】vcrRecord your test suites HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.项目地址https://gitcode.com/gh_mirrors/vc/vcr点击查看免费下载本篇指南讲解 VCRVideo Cassette Recorder请求匹配体系中的:uri匹配器它如何以完整请求 URI 为键将新请求与磁带cassette中记录的 HTTP 交互一一对应以及它为何与:method一起构成 VCR 的默认匹配策略。读完本文你将掌握:uri匹配器的语义边界端口归一化、主机尾点、查询串顺序等细节、如何在match_requests_on中显式启用它以及面对带时间戳等非确定性 URI 时如何借助VCR.request_matchers.uri_without_param优雅降级。什么是:uri请求匹配器VCR 的核心能力是录制测试套件中的 HTTP 交互并在后续测试运行中回放而回放的前提是把当前真实发起的请求与磁带中已录制的请求进行匹配。:uri匹配器就是承担这一职责的内置匹配器之一它直接比较两个请求的完整 URI只有 URI 完全一致才判定为匹配。在 lib/vcr/request_matcher_registry.rb 中:uri与其他内置匹配器一同注册register(:method) { |r1, r2| r1.method r2.method } register(:uri) { |r1, r2| r1.parsed_uri r2.parsed_uri } register(:body) { |r1, r2| r1.body r2.body } register(:headers) { |r1, r2| r1.headers r2.headers }可以看到:uri匹配器的实现是r1.parsed_uri r2.parsed_uri即对两个请求分别调用parsed_uri解析后的 URI 对象后做相等性比较而非简单地比较原始字符串。默认匹配策略:method:uri对于没有显式指定匹配方式的磁带VCR 默认同时使用:method和:uri两个匹配器。这一默认值定义在 lib/vcr/request_matcher_registry.rbDEFAULT_MATCHERS [:method, :uri]原因很朴素对于典型的 RESTful APIHTTP 方法与请求 URI 通常足以唯一确定资源 动作且二者在测试运行中具有确定性恰好构成既精确又稳定的匹配键。在 features/request_matching/README.md 中对此有明确说明默认按 HTTP 方法与 URI 匹配是因为它们通常具有确定性能完整标识典型 RESTful API 的资源与动作。从 lib/vcr/cassette/http_interaction_list.rb 的匹配逻辑看多个匹配器之间是**全部通过AND关系**只有配置的每一个匹配器都返回 true一次交互才算匹配成功def interaction_matches_request?(request, interaction) request_matchers.all? do |matcher_name| matcher VCR.request_matchers[matcher_name] matcher.matches?(request, interaction.request) end end也就是说默认配置下请求既要在方法上一致、又要在 URI 上完全一致才能命中磁带中的记录。完整实战用:uri匹配器回放两个交互下面复现官方文档docs/request_matching/uri.md与 Cucumber 特性features/request_matching/uri.feature中的完整示例。第一步准备已录制的磁带首先准备一个预先录制的磁带文件cassettes/example.yml其中包含两条记录URI 分别为http://example.com/foo与http://example.com/bar注意虽然录制时的 method 为post但示例中实际回放请求用的是get这里恰好能说明匹配只取决于你配置的匹配器组合--- http_interactions: - request: method: post uri: http://example.com/foo body: encoding: UTF-8 string: headers: {} response: status: code: 200 message: OK headers: Content-Length: - 12 body: encoding: UTF-8 string: foo response http_version: 1.1 recorded_at: Tue, 01 Nov 2011 04:58:44 GMT - request: method: post uri: http://example.com/bar body: encoding: UTF-8 string: headers: {} response: status: code: 200 message: OK headers: Content-Length: - 12 body: encoding: UTF-8 string: bar response http_version: 1.1 recorded_at: Tue, 01 Nov 2011 04:58:44 GMT recorded_with: VCR 2.0.0该 YAML 遵循 VCR 磁带的标准结构http_interactions数组下的每个元素包含requestmethod / uri / body / headers、responsestatus / headers / body / http_version与recorded_at三个部分recorded_with标记录制所用 VCR 版本。第二步编写使用:uri匹配器的测试脚本编写脚本uri_matching.rb通过match_requests_on: [:uri]显式指定仅按 URI 匹配http_lib与configuration为占位符具体取值见下文表格include_http_adapter_for(http_lib) require vcr VCR.configure do |c| configuration c.cassette_library_dir cassettes end VCR.use_cassette(example, match_requests_on: [:uri]) do puts Response for /bar: response_body_for(:get, http://example.com/bar) end VCR.use_cassette(example, match_requests_on: [:uri]) do puts Response for /foo: response_body_for(:get, http://example.com/foo) end其中c.cassette_library_dir cassettes指定磁带存放目录对应cassettes/example.yml磁带文件名取use_cassette的第一个参数examplematch_requests_on: [:uri]将匹配器收敛为仅 URI 一个维度此时即使请求的 method 与录制时不同也能命中示例中录制为post、回放为getresponse_body_for(:get, ...)是特性文件提供的小工具用于发起指定方法与 URI 的请求并返回响应体。第三步运行并验证运行ruby uri_matching.rb预期输出Response for /bar: bar response Response for /foo: foo response两个请求各自命中了磁带上 URI 完全一致的记录/bar拿到bar response/foo拿到foo response。这正是:uri匹配器按完整请求 URI 精确对应的行为写照。支持的 HTTP 库组合官方文档给出的示例覆盖了 VCR 通过不同 hook 适配的主流 HTTP 客户端configuration与http_lib可按需替换configurationhook 配置http_libHTTP 客户端c.hook_into :webmocknet/httpc.hook_into :webmockhttpclientc.hook_into :webmockcurbc.hook_into :webmockpatronc.hook_into :webmockem-http-requestc.hook_into :webmocktyphoeusc.hook_into :typhoeustyphoeusc.hook_into :exconexconc.hook_into :faradayfaraday (w/ net_http)c.hook_into :faradayfaraday (w/ typhoeus)例如使用标准库net/http时配置段填c.hook_into :webmock使用excon时则填c.hook_into :excon。hook 的底层适配逻辑可参考 lib/vcr/library_hooks/ 下的实现。:uri匹配的精确语义既然:uri是比较解析后的 URI 对象就需要理解parsed_uri到底是什么、哪些差异会被容忍、哪些差异会导致失配。相关的单元测试集中在 spec/lib/vcr/request_matcher_registry_spec.rb。parsed_uri 与端口归一化parsed_uri由 lib/vcr/structs.rb 定义本质是调用配置的uri_parser可通过c.uri_parser自定义解析请求 URIdef parsed_uri VCR.configuration.uri_parser.parse(uri) end更进一步Request在初始化时会对 URI 做标准端口剥离lib/vcr/structs.rb当 scheme 为http且端口为 80、或 scheme 为https且端口为 443 时会将该端口从 URI 中移除。因此http://example.com:80/foo与http://example.com/foo在:uri匹配下被视为等价——这消除了客户端与磁带间显式端口 vs 隐式默认端口的差异属于合理的容差。主机尾点trailing dot容差测试用例还验证了主机名结尾带不带.不影响:uri匹配spec/lib/vcr/request_matcher_registry_spec.rbit matches regardless of trailing . on host do matches subject[:uri].matches?( request_with(uri: http://foo.com./bar?baz7), request_with(uri: http://foo.com/bar?baz7) ) expect(matches).to be true end即http://foo.com./bar?baz7与http://foo.com/bar?baz7会匹配成功。严格失配的情形反过来任何实质性的 URI 差异都会导致失配spec/lib/vcr/request_matcher_registry_spec.rb主机不同foo1.comvsfoo2.com时:uri不匹配即使路径与查询串完全相同。同理路径不同、查询串不同也必然失配——毕竟:uri是完整 URI的匹配器任何组成部分的差异都算差异。查询串与参数顺序由于比较的是解析后的 URI 对象查询串的键值对顺序差异是否导致失配取决于所用uri_parser的实现与字符串形态。如果你希望匹配时忽略查询参数顺序、只关注参数集合本身应改用:query匹配器它通过可配置的query_parser将查询串解析为哈希再做比较顺序无关而:uri强调的始终是整条 URI 一致这一语义。从 lib/vcr/request_matcher_registry.rb 可以看到:query与:uri的实现思路不同register(:query) do |r1, r2| VCR.configuration.query_parser.call(r1.parsed_uri.query.to_s) VCR.configuration.query_parser.call(r2.parsed_uri.query.to_s) end多个匹配交互时的回放顺序当磁带上存在多条都能命中同一请求的交互时VCR 会按先进先出的顺序回放第一次匹配取第一条响应第二次匹配取第二条响应依此类推见 features/request_matching/README.md 的说明以及 lib/vcr/cassette/http_interaction_list.rb 中匹配后即从剩余列表中取出的实现。这也是本文示例里bar与foo能各自拿到正确响应的前提。与其他匹配器协同何时只配:uri:uri不是唯一的 URI 相关匹配器lib/vcr/request_matcher_registry.rb 中还内置了更细粒度的选择匹配器比较内容典型场景:uri完整 URI解析后对象相等请求目标完全确定、可精确复现:host仅主机名忽略尾点不关心路径与参数只关心访问了哪个主机:path仅 URI 路径不关心主机与查询参数只关心资源路径:query仅查询串顺序无关只关心参数集合忽略路径与主机差异:methodHTTP 方法配合其他匹配器缩小范围组合使用如match_requests_on: [:method, :host, :path]可以把匹配粒度从完整 URI放松到主机 路径适合那些请求参数会变化的场景。:uri的定位始终是最严格、最完整的 URI 级匹配适合请求形态稳定、希望精确复现每次请求的测试。面对非确定性 URIuri_without_param的降级方案:uri匹配器有一个典型痛点如果请求 URI 每次都携带不同的时间戳、随机 token 或签名参数例如http://example.com/search?qfootimestamp1316920490那么两次运行永远不可能产生完全相同的 URI:uri必然失配。这是 docs/request_matching/uri.md 提到的默认匹配器的主要局限。针对这一常见需求VCR 在 lib/vcr/request_matcher_registry.rb 提供了uri_without_param及复数别名uri_without_params动态匹配器它在比较 URI 前先剔除指定名称的查询参数VCR.use_cassette(example, match_requests_on: [ :method, VCR.request_matchers.uri_without_param(:timestamp) ]) { }其底层实现URIWithoutParamsMatcherlib/vcr/request_matcher_registry.rb会把查询串按切分、剥离指定键并兼容tag[]这类数组参数写法后重新拼接再比较。细节可参考配套文档 docs/request_matching/uri_without_param.md那里有完整的q...timestamp...实战示例。小结:uri匹配器是 VCR 请求匹配体系的地基它与:method一起构成默认匹配策略以解析后 URI 对象相等为判据提供精确、确定性的回放。使用match_requests_on: [:uri]可以显式启用它面对标准端口、主机尾点等无害差异VCR 已内置容差而当 URI 中存在无法复现的动态参数时则应升级到uri_without_param或自定义匹配器。想深入了解整套匹配体系可继续阅读请求匹配专题下的其他文档method、host、path、query、custom_matcher以及请求匹配总览 features/request_matching/README.md。赞分享测试开发工具【免费下载链接】vcrRecord your test suites HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.项目地址https://gitcode.com/gh_mirrors/vc/vcr点击查看免费下载相关推荐VCR 请求匹配指南使用 :path 匹配器按 URI 路径回放 HTTP 交互VCR 请求匹配指南使用 :path 匹配器按 URI 路径回放 HTTP 交互 本文聚焦 VCR 内置请求匹配器 :path 它只比较请求 URI 的 p测试开发工具VCR 请求匹配器 :body_as_json 详解基于 JSON 语义的请求体匹配实战指南VCR 请求匹配器 :body_as_json 详解基于 JSON 语义的请求体匹配实战指南 VCR 是 Ruby 生态中用于录制测试套件 HTTP 交互、并测试开发工具npm config 命令完全指南配置文件管理、六个子命令详解与底层实现npm config 命令完全指南配置文件管理、六个子命令详解与底层实现 本文是 npmJavaScript 包管理器官方命令行工具中 npm confi测试开发工具上一篇Windows Terminal文件拖放功能终极指南告别手动输入路径的烦恼下一篇ngxtop指标计算精度浮点数运算与四舍五入策略完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考