单元测试图形

是否有单元测试代码生成图形的标准最佳做法？我正在专门研究Java和jUnit，但我认为这个概念也适用于其他语言。单元测试图形

到目前为止，我可以拿出最好的是使用的Mockito嘲笑Graphics对象，并断言预先计算的东西，如（伪）：

assert that graphics.drawString was called with ("abc", 50, 100) 
assert that graphics.setBackgroundColor was called with Color.RED

虽然这是一个好主意，我想知道这是否是正确的方法，或者是否有更多的测试图形代码的已建立的实践。

来源

2013-02-19 Mike Clark

你是否考虑从图形中获取图像并与从资源读取的图像文件进行比较？ – 2013-02-19 15:49:24

@guido - 这是一个很好的建议，我还没有探索。绝对值得一看。 – 2013-02-19 15:57:34

我不知道这是否是成立的做法，但我会考虑Batik项目中的SVGGraphics2D模拟图形，并比较生成的SVG文件。

与比较二进制文件相比，SVG文件是相对可读的XML文件，所以如果这两个文件不相同，您不仅知道存在问题，而且还会得到有关确切位置的良好提示的问题。

与您的解决方案相比，优势在于可以查看这些SVG文件（例如在浏览器中），因此所测试的场景是自我记录的。

来源

2013-02-19 16:03:09 lbalazscs

我将不得不看看这个班。我喜欢比较xml文件而不是原始图形上下文的声音。 – 2013-02-19 17:47:13

你可以使用类似Mockito的东西，并模拟你的图形对象。然后你可以验证方法drawString和setBackgroundColor被调用。以一些例子从here

喜欢的东西：

import static org.mockito.Mockito.*; 


Graphics graphics= mock(Graphics.class); 
//Run you code .... 

//verification that the methods were called 

verify(mockedList).drawString ("abc", 50, 100);

来源

2013-02-19 16:05:16

正如你所说，你可以测试你的计算和调用图形API。这很容易。但检查你是否正确使用图形api（并产生正确的图片），可能会非常困难。我知道一些公司会对生成的图形（例如网页）进行截图，并使用许多复杂的指标将其与预期结果进行比较。但通常不是降低成本的方法，而是一些经理的年度目标（比如'流程自动化'）。所以在你走这条路之前要三思而后行 - 通常不值得痛苦

来源

2013-02-19 17:11:02 piotrek

单元测试图形

回答

相关问题