Xna:模拟 Texture2D [英] Xna: Mocking Texture2D

问题描述

我正在编写 WinForms/Xna 应用程序，我需要某种方法来抽象出与我的控制器/模型代码中的 GraphicsDevice 的交互.

我创建了一个接口 IGraphicsService.我会用它来抽象出加载纹理之类的东西.我无法弄清楚的是当我需要返回某种纹理信息时该怎么做.我应该创建一个包装 Texture2D 的类吗?我担心这会产生不必要的开销.从长远来看，我希望能够创建某种 MockTexture2D.

这一切都是为了让我的应用程序更具可测试性.我不太担心速度，但如果有一些解决方案不会产生太多开销，那就太好了，因为最终我想用它来使我的游戏更具可测试性.有什么建议吗?

解决方案

我个人的观点是 GraphicsDevice 类太复杂了，无法模拟，不管是谁做了它，都会有更多的工作来实际指示模拟执行在他的测试中是正确的(尽管他的努力肯定会获得奖牌:D).

Visual Studio 的提取接口"重构只会让您完成一半.也许代码生成器可以创建一个完全转发的模拟.如果你担心性能，只要你的模拟界面反映了真实的图形设备，你可以做一些魔术#if..#endif 在发布版本中使用真实的 GraphicsDevice 并在调试版本中通过界面?

-

无论如何，对于我自己的单元测试，我实际上是在为我的单元测试创​​建一个隐形形式的真实图形设备.这非常有效，运行我的单元测试的构建代理在 VMware 虚拟机中的 Windows XP 上运行，使用 Gentoo Linux x64 作为主机操作系统.我正在使用着色器和渲染目标等测试实际的渲染代码.在性能方面，我也不能抱怨 - 1300 次测试在 10 秒内执行.

这是我用来创建伪模拟图形设备服务的代码:MockedGraphicsDeviceService.cs 及其单元测试:MockedGraphicsDeviceService.Test.cs

当然，缺点是您无法检查此类伪模拟图形设备中的任何期望(例如，是否调用 CreateTexture() 时宽度为 234，高度为 456?).采取一些巧妙的类设计来隔离逻辑，以便我可以测试我的图形类而不会破坏它们的抽象.至少我可以通过这种方式获得图形代码的测试覆盖率:)

I'm writing WinForms / Xna app and I need some way to abstract away interaction with the GraphicsDevice in my Controller / Model code.

I've created an interface IGraphicsService. I'll use that to abstract away things like loading textures. What I can't figure out though is what to do when I need to return some kind of Texture information. Should I create a class that wraps Texture2D? I'm worried this will incur unnecessary overhead. I would like to be able to create some kind of MockTexture2D in the long run.

This is all so that I can make my app more testable. I'm not so much worried about speed but it would be nice if there was some solution that won't incur to much overhead as eventually I want to use this to make my games more testable. Any suggestions?

解决方案

My personal opinion is that the GraphicsDevice class is too complex to be mocked and whoever did it despite this would have even more work to actually instruct the mock to do the right thing in his tests (though he should certainly get a medal for the effort :D).

Visual Studio's "Extract Interface" refactoring would only get you half the way there. Maybe a code generator could create a fully forwarding mock. If you worry about performance, as long as your mock interface mirrors the real graphics device, you could do some magic #if..#endif to use the real GraphicsDevice in a Release build and go through the interface in a Debug build?

-

Anyway, for my own unit tests, I'm actually creating a real graphics device on an invisible form for my unit tests. This works surprisingly well, the build agent running my unit tests runs on Windows XP in a VMware virtual machine, with Gentoo Linux x64 as the host OS. I'm testing actual rendering code with shaders and rendertargets and whatnot. Performance-wise, I also can't complain - 1300 tests execute in under 10 seconds.

This is the code I use to create the pseudo-mocked graphics device service: MockedGraphicsDeviceService.cs and its unit test: MockedGraphicsDeviceService.Test.cs

The drawback, of course, is that you cannot check for any expectations in such a pseudo-mocked graphics device (eg. did a call to CreateTexture() occur with a width of 234 and a height 456?). Takes some clever class design to isolate the logic enough so I can test my graphics classes without breaking up their abstraction. At least I can get test coverage on graphics code at all this way :)

这篇关于Xna:模拟 Texture2D的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！