GUI Test Driven Development

Doesn''t Beck mention somewhere in that book that it''s hard to do TDD with GUI stuff? Somewhere near the end?

There are test frameworks that you can already easily use. Check out NUnit for .Net languages.

As for how to come up with tests, that should come with more trial and error. But for starters, don't test on a per function basis. Go for higher level tests that mimic the way your code is used in a real environment.

A lot of tests you write you will most likely throw away if it's written too low level. Low level stuff are best tested the traditional debugger way.

High level tests are mostly only ever changed if the code's interface changes.

Make tests your servants and not the other way round, don't get so caught up in writing tests since that's not the final product really.

[edited by - Darkor on December 30, 2003 2:33:45 AM]

I recently stumbled upon a book on amazon titled "Unit Testing in Java." One of the reviews claims that the book does an excellent job explaining how to test drive a GUI. Even thuogh I''m not developing in Java, but C++, I hope to get some benefit from the information.

I''ve chosen to use CPPUnit as my TDD framework, but I looked into the Boost Testing Framework as well. I was wondering if anyone has anything to say about the qualities of those frameworks.

Thanks again

- Jason Citron
- www.jasoncitron.net

You could either 1) get some software or write your own that captures the GUI events being generated 2) simply write it so that the GUI are front-ends(which almost always are) to functions which you can easily write unit test for.

Personally I opt for the second option.

quote:

---

Original post by Clash
I''m just getting started developing a GUI Framework for a game I''m working on, and I really want to try using TDD. I just recently finished reading Kent Beck''s book about the topic and I think it''s an awesome idea. However, I can''t seem to figure out a way to come up with tests which can realistically verify graphical behavior. If anyone has any insight into this I would greatly appreciate it!

---

You''d have to manipulate the widget, then write code to examine the frame buffer for correct results.
You could make an input grabber, and visually inspect replays as you change stuff. Might be easier to just do it manually...

If you use the NetBeans dev env, there is a JUnit extension available specifically for GUI classes.

ld

There are many different levels that may be testable, and many ways to do it, here are some general ideas - some already mentioned:

For testing your actual graphics (not the GUI really) some sort of frame grabbing ability is the way to go, and it is often not hard to do (except for effects that happen post frame buffer (like some blur and mouse effects on some cards)) ...

For ANY kind of game testing, writing your game in such a way that it is scriptable ... this is a HUGE help ... usually this means an extra level of messaging, such as the end user''s mouse and keyboard messages getting processed and turned into command messages ... then you just script the command messages, not usually the mouse and keyboard levels ... but this feature is critical to being able to do many types of gameplay regression tests easily ... and it''s usually very easy to write ... just write a hook class that can listen to the messages going through your window, and save designated types ... and write another ability to "play back" these saved messages. Usually the only hard part is deciding if you want to save the "clock time" they we''re sent at, or the "game time" they we''re sent at ... so that when you play them back on slower or faster hardware, what is actually going to happen ...

For GUI testing, the easiest to write, hardest to use system I know is to catch UI events (like mouse and keyboard events) and record / playback / generate them as needed ... The reason this is hard to use is that when the GUI layout changes, so do the locations you want to move the mouse to to cause an action ... VERY inefficient for such scripting ...

Another level of GUI testing involves a GUI framework being written specifically to be usefull in a programatic (non-GUI) way. You controls are given logical names or IDs, and can be accessed via a heirarchy .. for example "InventorySection/ItemList/5" could mean given the current window, window->GetChild("InventorySection")->GetChild("ItemList")->GetChild("5"), or even window["InventorySection"]["ItemList"]["5"]; And so script can be written to do stuff like:

MouseMove,locationof("InventorySection/ItemList/5")
LeftButtonDown
MouseMove,locationof("CharacterSection")

to script the equiping of the 5th item in the characters inventory .. (just an example of the type of thing that isn''t too hard ... IF certain assumptions make sense - like make sure and build your system to issue and handle exceptions - for instance if there is no item 5, or if it''s location is offscreen) ...

This type of testing framework takes quite a bit of time up front to put into place and get to a confidence level in which you can be sure you are testing bugs in your actual program / GUI and not in your scripting / testing engine ... but once you reach that level, it rocks ... and even provides the building blocks for tutorials and other scripted events being possible ...