Hello All,

I am using Ruby/Gosu and writing TDD style using Rspec.  I am currently following the Ruby Tutorial "Star Chaser Game"

Could anyone give me an idea on how to open a Gosu::Window _without_ display?  The Rspec process preferrs to have most (not necessarily ALL) tests operate without GUI interaction.

To limit the discussion from the onset :
* Yes, I understand that not all operations should run sans-GUI.  I am focusing this question on the subset of methods/operations that _should_ be able to run sans-GUI
* The behaviour here (beyond screen flashing of the displayed window), is that the main window is "rebuilt" for every test (TDD Setup) in order to provide a "clean" environment for every test.  I have not yet investigated framework-level test setup, which is possible but suboptimal.

Thanks for your thoughts and ideas.

Peter Fitzgibbons
peter.fitzgibbons@gmail.com

Gosu does not support that. Can you just mock out Gosu::Window to be something that will call its draw and update in a loop? Is resource loading the problem?

My hunch is still that unit tests and simulations of any kind don't mix very well, but I like being proven wrong ;)

Hi,

Not sure what you meant by "simulations"... do you mean mocking?

Actually, to me the primary question is "what is the 'glue' ? "  Identifiying the separation between the library and "your code" is the defining factor in creating mocks.  While it's important to test as much of the "application" as possible, eventually there will be edges and points where the framework gets in the way... sometimes though, it gets a bit iffy on exactly what part is "framework".

I agree with you, the best option is to mock Gosu::Window.  That's my next todo: Read the C++ Gosu::Window source (not the wrapper... the gosu lib), and understand the options and methods... then I will feel comfortable mocking it.  Black-box mocking is fun sometimes too!

Here is an example apillet wrote for me to explain how I could do TDD for game dev.

Here is an instantiation of the main window game, without showing it, and proving that an actor after being killed is indeed removed from the update and draw queues.
It doesn't do "running" tests (as in calling draw and update every 16.66ms) but I think it makes a point about how you could do tests.

https://gist.github.com/d4f3c7a8c4cce07c138d

I think the problem when doing testing is in HOW to test. What are the questions you need to ask (and the testing framework needs to answer) to do successful TDD.