Hey. Where I work we very thoroughly test GUI code which uses conventional GUI elements, or which runs in a browser. However, we do not call these 'unit tests' - we call them system or functional or acceptance tests (these terms are all synonymous.) We still use unittest.TestCase to write them though, albeit augmented with many utility methods to do things like open windows, move the mouse, etc.
Apologies if I'm muddying the waters by quibbling about definitions, but just in case it's useful to define terms: A unit test of the same code might call the same functions, but it would pass in harmless parameters or maybe mock out called subfunctions or submodules in order to prevent actual interaction with the GUI library. The point being, you should be able to run unit tests in parallel, or without any GUI installed, or on a different OS, and that shouldn't affect whether they pass or fail. Your unit test suite should run in less than a second, and that's generally not possible if you're actually opening windows and the like. However, we only write such system tests for business GUI applications, using Windows Forms or Django forms, etc. For OpenGL or pyglet applications, it's much harder to do true end-to-end tests, because there is no obvious programmatic way to query the resulting state of the GUI. e.g. there are no equivalents of things like 'assertTrue(checkbox.Enabled)' - because the screen is just a big unstructured array of pixels. To my mind, there are a few possible approaches: 1) Write one or two really rough and ready 'smoke tests' that fire up your applications, assert that a window is openened, that the screen is mostly color X, that the framerate is within expected bounds, then quit with a pass. 2) You might write tests which really examine the state of the screen to be able to assert that the correct menus are displayed, that the player character moves left and right, etc. I believe that in the general case, this is very time consuming and isn't worth the effort. I'd *love* to be shown that I'm wrong, but I think to do this right is a Hard Problem. 3) Alternatively, you could simply acceptance test your application by interrogating the state of your own GUI layer. This is the equivalent of assertTrue(checkbox.Enabled), but instead of 3rd party 'checkbox', you're using your own GUI classes, whatever they are. These GUI classes would be unit tested (as would be the rest of your application.) You'd have no actual assurance that your application actually worked end-to-end, but I think this approach, coupled with approach (1), is about the best bang-for-buck you could hope to achieve. 4) You could mock out layers like OpenGL or pyglet, and assert that the expected calls were made of them when you put the game into a particular state. The problem is that the transformation from 'game state X' to 'opengl calls A,B and C' is quite a complex one, and prone to frequent change, so this sounds hard to me. I once asked Kent Beck for suggestions testing fullscreen graphics apps like games, and he recommended a combination of (1) and (3). Best regards, On Apr 1, 2:40 pm, greenmoss <[email protected]> wrote: > All, > > Does anyone here use unit tests for your graphics elements? For > example, I would like to test "resize the window, and ensure that > element foo has coordinates x,y". Is this possible? > > Thanks -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. 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.
