¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Single Messages Topics Expanded Polls

Re: [TDD] How do you write tests if you aren't sure what the result should be?

 

"// 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;
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
Join [email protected] to automatically receive all group messages.