如何使用TDD进行图像渲染项目？
我正在编写一个光线追踪器，我想使用 TDD、自上而下的方法对其进行编码。 我不想让您厌倦这些细节，所以简而言之，该程序将以您给它一个指定的场景（例如球体的坐标及其半径）的方式工作，并且它将输出一个图像渲染的 3d 球体。 我到底如何才能首先测试这种行为？
我知道我可以首先测试 .render() 函数内部的一些内部算法，但我想自上而下，而且我无法提前预测生成的图像。我知道我可以测试它是否为全黑或指定大小，但如果我想严格使用 TDD，这些测试不会让我有任何结果：“你不应实现超过通过测试所需的内容”。
那么，有什么想法吗？
I'm writing a raytracer, and I would like to code it using TDD, top-down approach.
I don't wan't to bore you with the details so in a nutshell the program will work in a way that you give it a specified scene (for example coordinates of a sphere and its radius), and it will output an image with 3d sphere rendered.
How in the world can I test first such behaviour?
I know I can test first some inner algorithms that are inside that .render() function, but I would like to go top-down, and I just can't anticipate the generated image in advance. I know I can test it for beeing all black or specified size, but if I would like to be strict in using TDD those tests wouldn't get me anywhere: "you shall not implement more than its required to pass the test".
So, any thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不要尝试自动测试图像。您的眼球在验证图像方面比您可能编写的任何代码都要好得多。作为回归测试，您可以捕获图像输出并进行像素比较，但这将是一个脆弱的回归测试，而不是 TDD 单元测试。
将渲染逻辑提取到单独的可测试类中。我认为您可以 TDD 进行大量计算和算法，除非您能找到现有的库（这可能值得寻找）。 TDD 与设计有关，现在它告诉您将渲染算法与显示分开。
Do not try to automate testing the image. Your eyeballs are infinitely better at verifying images than any code you could possibly write. As a regression test you can capture the image output and do a pixel compare, but that will be a fragile regression test, not a TDD unit test.
Extract the rendering logic into separate testable classes. I assume there will be lots of calculations and algorithms you can TDD unless you can find an existing library (which is probably worth looking for). TDD is about design and right now it is telling you to separate out the rendering algorithm from the display.
显然，您无法预测给定用例的确切图像，否则您就不需要该项目。即使是最狂热的 TDD 倡导者也不会要求您首先编写完整的测试。但是，您可以先编写加载图像和比较程序输出部分，然后再插入实际图像，我实际上建议这样做。从使用建议的 API 开始总是一个好主意，因为它可以暴露您永远不会想到的问题，直到为时已晚。
也有可能您已经知道的不是确切的图像，而是您想要测试的图像的某些属性。例如，如果渲染强制性反射金属球体，您可能很清楚图像的某些区域必须有多亮（大约），或者某些部分必须对称等。编写这些测试是一个好主意第一的。 （我维护一个自动生成图表的测试套件，它们包含诸如“所有十种颜色必须在该图像中可见”之类的测试，即同心圆应该首先绘制最大的。当然，光线跟踪输出要复杂得多，但原则适用。）
Obviously you can't anticipate the exact image for a given use case, or you wouldn't need the project. Not even the most rabid TDD advocate would demand that you write the complete test first. However, you may well write the load-image-and-compare-to-program-output part first and insert the actual image later, and I would actually recommend doing that. Starting out with a use of the proposed API is always a good idea, as it can expose issues that you would otherwise never think about until it's too late.
It is also possible that you already know, not the exact image, but certain properties of the image that you want to test. For instance, if you render the obligatory reflecting metal sphere, you may well know how bright (approximately) certain areas of the image have to be, or that certain parts have to be symmetrical, etc. It is a good idea to write those tests first. (I maintain a test suite for automatically generated diagrams, and they contain tests such as "all ten colours must be visible in this image", i.e. concentric circles should be drawn largest-first. Raytracing output is, of course, much more complicated, but the principle applies.)