可视化(3D图形)框架的单元测试
这是这问题的后续。当你有一个科学算法库时，我在问如何进行单元测试。我现在有一个类似的问题，但与另一个项目。
我正在为DirectX、OpenGl、WebGl、Silverlight、WPF进行3D图形引擎框架的抽象，以及基本上在C#上的任何3D API，称为渲染.NET。设想如下，该项目是由我的一小群同事开发的，他们都在同一个办公室工作。我们都是计算机科学家，对软件工程界和实践的了解并不多。我甚至很难说服从Subversion到Git，并在Codeplex上发布这个项目。这个项目正在变得越来越大(大约80K的C#线)，现在它覆盖了DirectX和OpenGl的大部分，直到ShaderModel5.0，所以它并不像链接问题中描述的那样是一个人的项目。我们还希望鼓励开源社区进行协作。
到目前为止，我们通过编写小型应用程序进行测试，这些应用程序涉及初始化所有设备和资源、设置场景和绘图。问题是，我不知道如何使它与众不同，我的意思是，如何设计测试框架的特定特性的小测试用例，比如资源分配、原始镶嵌、着色编译等等，而不必重新创建整个引擎初始化。对于其中的一些情况，我可以想到有用的模拟，但一般来说，当输出是可视的(图像或动画场景)时，我如何测试渲染算法的正确性？现在，我们想出的最聪明的方法是将相同的场景呈现给软件渲染器DirectX和OpenGl，并逐个像素地比较它们，但是API的微小变化使得产生的图像有足够的不同，可以通过测试而不是实际的bug。
那么，这里的“正确”测试方法是什么呢？
回答 1
Software Engineering用户
发布于 2013-02-26 22:09:45
“正确”的测试方法是将绘图逻辑与DirectX或OpenGL调用分离开来，这样您就可以模拟后者(并且作为另一个用例，可以对DirectX或OpenGL使用相同的业务逻辑)。
您不想测试DirectX或OpenGL是否正确工作--这是微软的工作。您还希望只编写一次设备初始化代码并进行一次测试(然后再重用)，因此对该部分进行手动测试应该是负担得起的。如果您也想自动测试该部分，请使用您的逐像素方法，但要使用非常简单的测试绘图。因此，专注于为您的解耦绘图逻辑编写自动回归测试，这将给您带来最大的好处。
因此，整个想法是将您的代码拆分成真正独立的组件--您的DirectX初始化不应该耦合到绘图逻辑，绘图逻辑不应该依赖于DirectX --这使得您的程序可以测试。
编辑:找到了这个前职位对OpenGL代码的单元测试，只有几个答案，但也许它会带来一些额外的洞察力。
https://softwareengineering.stackexchange.com/questions/188495
复制相似问题
腾讯云开发者
