gpt4 book ai didi

unit-testing - 通过 HeadlessApplication 调用 ShaderProgram(例如 Stage)的单元测试 Libgdx 类

转载 作者:行者123 更新时间:2023-12-04 21:30:54 25 4
gpt4 key购买 nike

我正在尝试对 core 进行单元测试我的 libgdx 应用程序包。

模拟 ShaderProgram 的最佳方法是什么?这样可以测试根类?

鉴于 Libgdx 测试运行程序的以下初始化,

init {
val conf = HeadlessApplicationConfiguration()

HeadlessApplication(this, conf)
Gdx.gl = mock(GL20::class.java)
Gdx.gl20 = mock(GL20::class.java)
Gdx.gl30 = mock(GL30::class.java)
Gdx.graphics = mock(Graphics::class.java)
`when`(Gdx.graphics.height).thenReturn(dimensions)
`when`(Gdx.graphics.width).thenReturn(dimensions)
}

和被测函数(在 Application Listener 的子类中),
override fun create() {
...
stage = Stage(ScreenViewport())
...
}

尝试编译着色器时,Stage 内部发生错误。

即,在 SpriteBatch.java来自 com.badlogic.gdx.graphics.g2d ,
ShaderProgram shader = new ShaderProgram(vertexShader, fragmentShader);
if (shader.isCompiled() == false) throw new IllegalArgumentException("Error compiling shader: " + shader.getLog());
shader.isCompiled()对于 HeadlessApplication 似乎总是返回 false .

最佳答案

由于到目前为止没有答案,我想分享我目前的知识/意见:

首先,我们需要问一个问题:我们甚至可以为 GUI 编写单元测试吗?如果您想要深入的答案,请查看 this question .总结:您可以通过从帧缓冲区计算哈希值来对您的 GUI 进行单元测试,但一般建议是将尽可能多的逻辑移出您的 GUI,并且根本不要对您的 GUI 进行单元测试。除此之外,我和大多数运行代码的服务器都没有对 OpenGL 的硬件支持。假设我们不想为软件渲染烦恼,那么对 GUI 本身进行单元测试是没有选择的。

基于这些信息,我认为我的逻辑与我的 GUI 分离得不够好。但是当进一步研究 scene2d 和大量教程时,很明显,scene2d 希望您通过设计将代码的逻辑和 GUI 部分结合起来,参见 this question以供引用。

假设您同意scene2d 很难将您的逻辑和GUI 分开的观点,我们现在正面临op 的问题,而常见的解决方案并不适用。

在我看来,libGDX 的所有元素都应该与 HeadlessBackend 完全兼容,这不是 libGDX 的设计缺陷。到目前为止,我想出的唯一解决方法是在需要时模拟 SpriteBatch 并将其传递给舞台:

val stage = Stage(myViewport, if (isHeadless) mock(SpriteBatch::class.java) else SpriteBatch())

虽然这允许您正常使用 Stage,但我认为它不是一个真正的解决方案,因为您需要编写代码测试感知。

关于unit-testing - 通过 HeadlessApplication 调用 ShaderProgram(例如 Stage)的单元测试 Libgdx 类,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51728471/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com