【问题标题】:Spock classpath resource not resolvableSpock 类路径资源不可解析
【发布时间】:2017-02-27 23:12:23
【问题描述】:

在 Spock 单元测试中,一个方法会拉入资源 JSON 文件...在检索基于类路径的资源的方法中:

Myclass.classpath.getResource('/someJsonfile.json') //Works in WAR arhcive, but fails during a spock test and returns null

上述方法不起作用,但在部署 WAR 时该功能可以正常工作

以下在 Spock 中用于解析类路径资源,但是会破坏 WAR 的功能

System.getResource('/someJsonfile.json') //Works in spock test, but breaks functionality when inside WAR   

【问题讨论】:

  • 你试过了吗:this.getClass().getResource('/someJsonfile.json') 或者,如果 Myclass 是 groovy,Myclass.getResource('/someJsonfile.json'),或者如果它是 java Myclass.class.getResource('/someJsonfile.json')
  • 谢谢,是的,上面的代码是用 Groovy 运行的 :) ...问题是一旦打包到 WAR 中就可以工作了...我可以检查这些细微的差异是否会产生影响,并且回来报告。再次感谢!

标签: java groovy classpath spock


【解决方案1】:

我通常在较大的项目中做的是:

  • 为测试资源创建一个单独的模块。顺便说一句,您还可以在那里放置基本的东西,例如 Spock 扩展、基本规范、Geb 配置、测试依赖项。重要提示:在测试资源模块中,您将所有内容放在src/main 下,不是 src/test。您还可以使用 compilenot test 范围导入所有内容。然后从模块创建一个普通的 JAR。
  • 现在您可以在任何需要的地方导入带有测试范围的测试资源模块。然后您的资源加载问题也得到了解决,因为您始终可以依赖从 JAR 中提取的资源。
  • 您可能还想更进一步,创建一个带有托管测试依赖项的 BoM(物料清单),在您需要对 JUnit、Spock、Geb、Selenium 等进行干净版本管理的任何地方导入该 BoM。

因此,通过导入 BoM,您可以获得版本管理,通过导入测试资源,您可以获得实际资源、测试依赖项和测试基类。结果是一组可重用的测试类和资源以及干净的导入模块。最后但并非最不重要的一点是,无论您是在容器内部还是外部进行测试,您都可以始终以相同的方式加载资源。


更新:

这里有链接

它非常简单,在企业环境中特别有用。

【讨论】:

  • 感谢您的建议,我认为这不会在我的公司环境中工作......我不确定我是否喜欢更改代码以使测试正常工作的想法。
  • “我不认为它会起作用”只是一个杀手级的短语,而不是一个论点。我将如何回答这样的声明?我只能说,我在大型企业项目中指导的最后一个开发团队(我是 Scrum 教练)正是使用这种方法来避免多模块项目中的冗余并拥有干净的测试资源和依赖关系。与生产代码相比,测试不是第二类工件!值得一提的是,我在 GitHub 上共享了三个示例项目(BoM、资源/依赖项工件和一个使用它们的项目),并添加了指向我的答案的链接。享受 - 或忽略。
  • 您还没有准备好更改测试代码以使其正常工作?!?如果你不愿意修复它,你为什么在这里问一个问题?
  • 当我说更改代码时,我并没有向您明确说明...我显然愿意更改测试代码,但我发布的代码片段是方法内的“真实代码”这在我的 spock 测试中被调用。我一定会看看你的例子谢谢......虽然我在公司环境中,但我显然不能做太疯狂的事情。
  • 哦,是生产资源,不是测试资源。那么很简单:MyClass.class.getClassLoader().getResourceAsStream("resource.txt") 可以在本地和 JAR 中工作,也可以在生产和测试代码中工作。对我来说,无论如何。您需要从同一个工件通过生产类的类加载器 - 非常简单。
猜你喜欢
  • 2011-08-21
  • 2016-12-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多