内容
我正在开发一个Web应用程序,该应用程序可以利用为Postman构建的一套REST测试。
其思想是,您可以使用Postman作为REST客户机针对应用程序运行时手动运行测试,并且Maven pom将纽曼配置为在触发构建时在CI管道中自动运行这些测试,作为集成测试。
这在过去运行得相当好。
要求
然而,由于业务逻辑的彻底改革,许多测试现在需要二进制主体作为POST请求中的文件资源(大多数是zip存档)。
我需要这些测试在3种情况下工作:
1.在本地使用Postman对Web应用程序的运行时运行单个测试时手动执行
1.半手动操作同上,但通过触发Postman中的跑步者
1.在我们管道的集成测试阶段,当maven启动纽曼时,会自动启动
为了确保每个请求中的文件路径都能正常工作,而不管测试的运行方式如何,我在每个配置文件中添加了一个Postman环境变量。然后,该变量将被相关请求中的集合使用,例如:
"body": {
"mode": "file",
"file": {
"src": "{{postman_resources_path}}/empty.zip"
}
},
其想法是:
- 在本地,您手动覆盖概要文件中
postman_resources_path
的值,以便指向您的计算机中的绝对路径(例如,只是在源代码控制中拥有资源的位置)-这将为手动测试和本地运行程序解决该问题 - 对于CI管道,同样的方法也适用于指向相对于
--working-dir
值的路径的默认值,该值将在已经用于运行newman的exec-maven-plugin中的纽曼命令行参数化中设置
问题
虽然我还没有机会用这些假设来测试管道,但我已经注意到这在本地不起作用。
查看请求时,我可以看到环境变量未被解析:
相反,下面是我在运行请求的配置文件中手动设置的值:
TL;DR因为找不到资源,所以要求失败。
我找到的最相关的文献并没有完全解决我的用例,但给出的解决方案似乎遵循了类似的方向:“变量化”路径-请参阅here。
我找不到任何足够具体的 Postman 参考。
1条答案
按热度按时间lsmd5eda1#
我想我找到了一些东西,但我还不会接受我自己的答案。
它可能比最初看起来更简单。
此Postman文档页面声明:
当您发送带有请求正文的表单数据文件或二进制文件时,Postman会将该文件的路径保存为集合的一部分。该文件路径是相对于您的工作目录的。
如果我修改原始集合json以确保只有文件名(或任何相对路径)是文件定义中“src”键的值,并在我的Postman客户端中手动设置工作目录,似乎可以正确解析文件--〉文件路径中不需要(非工作)变量。
工作目录设置似乎没有保存在集合中,这意味着为本地客户机手动进行一次性设置,并使用
--working-dir
和纽曼一起使用应该可以达到这个目的。一旦我成功地和纽曼一起测试过,我就会自我接受。