單元測試圖形

是否有單元測試代碼生成圖形的標準最佳做法？我正在專門研究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

單元測試圖形

回答

相關問題