As has already been suggested, it potentially sounds like there is a lack of adequate separation of front-end from the underlying model, which is making it difficult to have practical tests.
You say:
<<If I was doing this without unit tests, I would run the game wait for it to keep bouncing for x number of seconds, and see if the marker showed up in the right place or not. Not a very efficient test.>>
Im not certain I understand what you mean here, but if I do get you, then if your UI is decoupled from the underlying (gravity?) model, why not just compute the sequence of steps (according to some test 'script' of actions) as fast as possible, not in real time? It might be reasonable to have an acceptance test where you have some dummy timer that operates as fast as computer can operate rather than according to some actual temporal clock - since I don't see how this affects the functioning of the program?
You can achieve this through dependency injection and mocks (test doubles) - depending on how you intend to design it. So for example, you might consider having a dummy game clock that just works as fast as the processor can run, while the game clock you use in production is synchronised to some real clock. In your acceptance test, you would use this dummy clock, so that the test runs faster than real-time?
Daz
toggle quoted message
Show quoted text
On 15/02/13 14:48, Avi Kessner wrote:
"// check the position of our hero
assert( penguin.position, whereEverYouWantItToBe );"
Yes, that is exactly what I want to know :) I don't know where I want the
penguin to end up.
What I have done for now is to "cheat". I create a new scene where the
penguin always ends up on the mark that I have displayed, and I use the
current velocity to decide when to add this scene to the end of the
animation. I don't like this solution for multiple reasons, one of
those problems is that the penguin is now flying for slightly longer than
it's supposed to. I came to the group seeing if there are "proper" ways
to solving this sort of problem. The creation of multiple scenarios and
test files sounds like it's the right direction, but I'm unclear on how
that goal would work.
It doesn't seem right to me that proper TDD would require that I cheat at
my requirements :)
"One thing that tells you this is going to be hard is the name of the test
In this case, I keep getting names like this:
- When_The_Penguin_Is_Hit_Hard_It_Bounces_Many_Times_And_
Lands_A_Long_Way_Away
Hmmm!
That is a very excellent point!
quote cut short for brevity...
" It will not TEACH you what the domain is.
Sorry :-(
Amir "
All very good points. Part of the problem here is that I feel that it's
not just laziness that causes me to not properly know the domain, (though
that can certainly be part of it) but also, I think in essence
the solution isn't knowable. Because of various speeds of computers,
rendering time, inaccuracy of timers etc. This reminds me of the Theta
notation for algorithms, and makes me wonder if you can write unit tests
when the information is so inherently fuzzy. Surely it must be possible.
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 3:36 PM, sh <shvfn@...> wrote:
**
Hi Avi,
I'm still new to TDD and I'm not sure, if I really understand your
specific problem, so maybe this is rubbish not how it should be done.
I'll try anyway:
If I understand this correctly, there is no trivial algorithm to compute
the position of the marker, because the 'algorithm' is the behaviour of
the game engine, isn't it?
So the position of the marker is determined by the level design, the
collision detection (or physics system and properties like gravity) of
the game engine and the game objects' properties (velocity, friction, ?)
over time.
If that is correct, it should be possible to write a top-down test like
this (for your example):
// pseudo code
penguin = new GameObject( position, velocity, rotation, shape, whatever );
// let's say physicsWorld computes the position and collisions of the
gameObjects
physicsWorld.add( penguin );
// deltaTime in Milliseconds
fixedDeltaTimeMS = 20;ation, we were able to define our
numFrames = 100;
// evaluate the position for the next two seconds
for ( i=0; i < numFrames; i++ ) {
physicsWorld.update( fixedDeltaTimeMS );
}
// check the position of our hero
assert( penguin.position, whereEverYouWantItToBe );
If you can test like this, you can break the tests down:
shouldMove100PixelWithVelocity100PerSecond();
shouldBounceFiveTimesInSixSecondsWhenFallingFromHeight200(); // whatever :)
If your systems allow testing like this, it should always be possible to
"peek into the future" to determine the position of a game object in x
milliseconds. And then it is not be too complicated to determine whether
the marker is onscreen or offscreen.
Hth,
Stefan
------------------------------------
Yahoo! Groups Links
