Автоматизированное тестирование на приложение OpenGL
public static int GetWeekNumber(DateTime dtPassed)
{
CultureInfo ciCurr = CultureInfo.CurrentCulture;
int weekNum = ciCurr.Calendar.GetWeekOfYear(dtPassed, CalendarWeekRule.FirstFourDayWeek, DayOfWeek.Monday);
return weekNum;
}
2 ответа
I have written unit-tests for C++ (Qt on Linux) & OpenGL before. I don't know any reason it shouldn't work for Java too.
The things which worked for me are:
Abstract your OpenGL context provider so the rest of your code is independent of it. In my case the main app used Qt's QGLWidget, but the unittests used a pbuffer-based one which I could create with no windowing infrastructure at all (other than a designated X11 DISPLAY). Later I added an "offscreen Mesa" (pure software OpenGL implementation) so they'd even work on a headless build machine with no GPU at all.
Keep your OpenGL code independent of your GUI code. In my case the OpenGL "rendering engine" didn't know anything about Qt classes (e.g mouse events). Define your own testable API which isn't tied to any specific GUI concepts, and write tests for it.
In the unittests, read the contents back from the framebuffer using glReadPixels and either hit them with some assertions about which pixels should be particular values, or go down the regression-testing route and compare the framebuffer capture with a stored image you know is good (either from manual verification, or because it's produced from some other reference model).
Allow a bit of fuzziness in any image regression testing; most OpenGL implementations produce slightly different output.
(I didn't do this, but...) Ideally you want to be able to test the GUI layer by asserting that it makes the expected sequence of calls to your rendering engine in response to GUI activity. If it does that, and you're confident of your render layer because of the above tests... well, no need to actually do the rendering. So create a suitable mock object of your rendering layer for use when GUI testing (I'd imagine tests like "mouse drag from here to there results in a call to the rendering layer to set a particular transform matrix"... stuff like that).
Я думал об использовании инструмента сравнения изображений, такого как PDiff , для тестирования кода OpenGL, делая снимки, сохраняя их на диск и по сравнению с предыдущим результатом регрессии. Таким образом, всплывают действительно плохие вещи (отсутствующие текстуры), но незаметные для человека вещи (такие как упомянутые выше небольшие различия между реализациями) проходят нормально.
Кроме того, для автоматизации взаимодействия с пользователем классы графического интерфейса должны быть достаточно открытыми для для отправки событий или вызова «нажатие кнопки» или вам необходимо вручную вводить события ОС в свои приложения. Это возможно, но гораздо сложнее. Возможно, будет проще открыть слой GUI, если это Open Source.