So regarding pixel testing, are you referring to true "ignorant" pixel testing (eg reading frame buffer values)? I was recently talking to a friend who is a very good QA tester. He has done pixel-level UI testing, and says it has certain inherent difficulties which are not at first glance obvious. Things like the rgb values for *all* pixels in the frame buffer changing even though the test inputs are identical and the results also look identical to human eyes. FWIW, I asked him if there was any free way to do this kind of testing, and he pointed out "T-Plan Robot"; I'm unassociated with the project: http://sourceforge.net/projects/tplanrobot/.
Then again, if you're reading OpenGL memory instead, that would sidestep these kinds of problems entirely. If this is so, I apologize for interjecting an ignorant comment :) On Saturday, June 23, 2012 2:58:15 PM UTC-4, Winston wrote: > > I was thinking along the same lines--both testing pixels for specific > colors and having tests be in a separate process so they can be killed. > > -ww > > On Jun 23, 2012, at 10:03 AM, Jonathan Hartley wrote: > > > I think some of the manual tests could be automated. e.g. the font ones > could look for font-colored pixels in the output, to establish the > approximate rectangle that the font has been rendered in. > > > > If fatal crashes terminating the test run early is a persistent problem, > an idea for the future might be to convert tests which actually fire up a > window to do so in a new process, so that it the process-under-test could > crash without terminating the test run. > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/et7cxMCuYVkJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
