Nai*_*rou 21 c++ opengl tdd unit-testing
我已经开始了一个新的游戏项目,并决定为它学习和使用OpenGL(项目正在Windows和Linux上同时开发).与此同时,我对测试驱动开发也非常感兴趣,并且我正在努力编写单元测试,以便在任何实际代码之前进行设计.
但是,我认为我缺乏知识可能会让我感到沮丧,而且我一直试图为代码库的"渲染"部分编写单元测试.我希望有人可以给我一些关于如何继续的见解.
我知道我需要单独测试我与OpenGL的交互,而不是OpenGL本身.我能看到这样做的唯一方法是在某种程度上将OpenGL从我的其余代码中抽象出来,或者通过拦截OpenGL函数调用,或者通过创建一个全新的类接口,允许我创建该类的模拟版本用于测试.(更好的方法是将它们抽象到一个单独的命名空间中的一组非类函数而不是虚拟类抽象,但我不知道如何模拟它.)
但是,由于我还在学习OpenGL,所以我对这个抽象应该是什么样子只有一个概念.例如,我应该包装每个OpenGL调用,还是根据要完成的任务将它们分组到更高级别的函数中？瘦包装器只会调用特定的OpenGL函数,所以我不需要事先测试它们,但我最终可能需要包含大量函数.再说一遍,如果我走得太远,并且通过任务将多个OpenGL调用组合起来,我觉得我最终会在我开始的地方结束,使用OpenGL进行大量代码,本身需要在使用前进行测试.
中间地方在哪里？如何在学习使用OpenGL的同时事先进行适当的单元测试？
您无法自动测试渲染部分。为此，你需要一个有能力看到和识别图像的有知觉的生物。电脑不合格。
您可以自动测试资源创建是否成功 - VBO、纹理、着色器、显示列表 - 您可以对着色器进行单元测试以查找编译错误、测试数学库，您可以检测 OpenGL 错误，但无法测试渲染部分。您能做的最好的事情就是制作某种测试例程来渲染图片（可能是动画和交互式的）并询问它看起来是否正确。该测试不会 100% 可靠 - 可能在一种硬件上有效，但在其他硬件上无效，人类可能会错过错误等。
例如，我应该包装每个 OpenGL 调用吗？
不，这不值得。
或者根据要完成的任务将它们分组到更高级别的职能中？
编写一些调用/类来创建“纹理”、“网格”、“着色器程序”是有意义的，采用某种自动方式来获取统一位置（如果您使用着色器），也许是一些用于自动释放的类OpenGL 资源（即具有 glDelete*** 或具有 glIsTexture 等函数的资源），但仅此而已。通常，您不应该引入额外的抽象/类，除非需要它们 - 因为这将是额外的工作而没有任何收获。