What's Junit in a 3d Gui world?

hi

??? I am starting a new project with java3d. I got used to junit in a previous project. I have looked around for GUI testers for java. I found Abbot sofar.

What I would like to know is how experienced game developers ( which I am not ) organize systemtesting.

Any tips? Thx

jimcp

Um well…

For unit testing I just write unit tests as I design code modules.

For game testing, generally its done by people who sit and play the game for hours on hours…

Dunno how much that helps.

3D interfaces don’t really behave like normal Swing or AWT interfaces and the bad news is that I know of no testing tools for them because there aren’t really any standard ways of doing it or libraries they are based on. There is no 3D equivalent of a form or a button or any other 2D widget. If you want to use those you will either be using the 2D library for those parts of your interface and just having a 3D window, in which case you can test as normal, or you will be rolling your own 2D interface, in which case you can integrate it with whatever testing tool seems appropriate…

A big problem is testing results.

You could capture and journal a set of inputs and play them back froma file easily enough, but the only way to test for correctness of output is to screen scrape. This is ofcourse excruciatingly slow. In addition, just the act of slowing down the frame rate will produce slightly different looking frames in any real-time game.

So I cannot imagine any way to automate that sort of testing.

[quote]A big problem is testing results.

You could capture and journal a set of inputs and play them back froma file easily enough, but the only way to test for correctness of output is to screen scrape.
[/quote]
Whilst I see what you’re thinking, it’s not really true. You’re thinking in the wrong direction, imagining that the user wants to unit-test the rendering library. Whilst that would be nice it’s a huge amount of effort that doesn’t really do you any good - it’s not sensible unit-testing, it’s too brute-force.

With a scenegraph, a lot of what you want to check is actually “are the correct thigns in the correct places when I try to render”. Assuming there are no bugs in the renderer, and none in the SG (yeah, right, but … ) then you can write unit tests that examine the current state and see what’s actually being rendered and compare to what is known should be rendered. It’s one of the main points of having a SG - abstraction ;D.

So, AFAICS, it boils down to "how much runtime reflection-esque / query access do you have to J3D, to:

  • the tree in memory
  • the PVS
  • the renderer FSM?"

With sufficient access to each, you can find out whehter your SG is correct, find out whether it’s rendering what it should (and check that your solid objects aren’t transparent!) and finally check that all your things that should be optimized out or switched off, or behaviours in certain states, are as you would expect.

All of which, IIRC, you can in fact do from within J3D?