Единица измерения графики

Question

Есть ли стандартная передовая практика для кода модульного тестирования, который генерирует графику? Я работаю специально с Java и jUnit, но я думаю, что эта концепция будет применяться и на других языках.

До сих пор, самое лучшее, что я могу придумать использует Mockito для имитации Graphics объекта и утверждать заранее рассчитанные вещи, такие как (псевдокод):

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

Хотя это все хорошо, Мне было интересно, правильно ли это сделать, или если существует более распространенная практика тестирования графического кода.

Answer 1

Я не знаю, была ли эта практика, но я бы рассмотрел SVGGraphics2D из проекта Batik для насмешливой графики и сравнения сгенерированных файлов SVG.

Преимущество перед сравнением двоичных файлов заключается в том, что SVG-файлы являются относительно читаемыми XML-файлами, поэтому, если эти два файла не равны, вы не только знаете, что есть проблема, но и получаете хороший намек на точное место проблемы.

Преимущество вашего решения в том, что эти файлы SVG можно просмотреть (например, в браузере), поэтому тестируемый сценарий является самодокументированным.

Answer 2

Вы можете использовать что-то вроде 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); 

Answer 3

, как вы упомянули, вы можете проверить свои расчеты и вызов графического API. это легко. но если вы правильно используете графику api (и создаете правильную картинку), это может быть очень сложно. Я знаю, что некоторые компании делают скриншоты сгенерированной графики (например, веб-страницы) и сравнивают ее с ожидаемым результатом, используя множество сложных показателей. но, как правило, это не способ снизить стоимость, но годовая цель одного менеджера (скажем, «автоматизация процессов»). так что подумайте дважды, прежде чем идти этим путем - обычно это не стоит боль