RE: How do you write tests if you aren't sure what the result should be?

OK, that makes it even simpler. 

This is where TDD can tell you whether you've reached your final destination
or not. You can calculate the exact point where the penguin should stop "in
the real world", and then specify what the allowed error is.

At this point you need to refine your algorithm, taking into account things
like the current framework, current location, elapsed time, etc. until the
test passes.

A.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Avi Kessner
Sent: Sunday, February 17, 2013 1:03 AM
To: [email protected]
Subject: RE: [TDD] How do you write tests if you aren't sure what the result
should be?

My comparison was supposed to be regarding the culmative calculation,  not
the per tick calculation.

Ill have to look up when velocity is multiplied vs when it's added.
On Feb 17, 2013 3:46 AM, "Amir Kolsky" <[email protected]> wrote:

> **
>
>
> I may be missing something about this whole discussion, but isn't the 
> dt part supposed to take care of the delta in time? I.e., the 
> variation should be in that, rather than in some factor.
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Edwin 
> Castro
> Sent: Saturday, February 16, 2013 2:59 PM
> To: Test Driven Development
> Subject: Re: [TDD] How do you write tests if you aren't sure what the 
> result should be?
>
> let f = new framerate
> let g = old framerate
>
> x += dt*(g/f) + f*v
>
> f = 32 and g = 30 gives me g/f = 30/32 = 0.9375
>
> On Sat, Feb 16, 2013 at 11:54 AM, Edwin Castro [email protected]> wrote:
>
> > Actually, this reminds me of my microcontrollers course back in 
> > college where we had to bridge between two different sampling rates...
> > In that course we had to actually use three different sampling rates 
> > so that we could control the two we really cared about. Of course, 
> > that was 13+ years ago so I don't have anything more concrete than that.
> >
> > I would find out where the 0.937 factor comes from because I would 
> > not expect it to be there... unless your calculations are based on 
> > the fact that in the previous frame the framerate was 30 and now it 
> > is 32 which implies you can calculate the factor by knowing the old 
> > and new
> framerates.
> >
> >
> > On Sat, Feb 16, 2013 at 11:51 AM, Edwin Castro [email protected]> wrote:
> >
> >> I would expect that the 0.937 factor is a calculated factor that 
> >> somehow incorporates the fact that you are comparing framerates of 
> >> 30
> and
> 32 fps...
> >> In other words, your calculations are relativistic and you are 
> >> trying to use classical equations.
> >>
> >>
> >> On Sat, Feb 16, 2013 at 11:47 AM, Avi Kessner [email protected]>
> wrote:
> >>
> >>> In the case of a flying penguin it doesn't work.
> >>> The basic formula for the penguin flying through the air is x += 
> >>> dt
> >>> + v If this is calculated 30 times per second you basically get x 
> >>> + += dt
> +
> >>> 30v, but if you calculate it 32 times per second, you get x +=
> >>> (dt*0.937) + 32v
> >>>
> >>> And in reality, you get a range of say 28-34 fps with it changing 
> >>> every frame.
> >>> That's why I thought it was a sort of heisenberg problem. I can 
> >>> either fix the time it takes, or I can fix the distance it goes, 
> >>> but I can't have both be variable. Using the idea that "The 
> >>> renderer produces time and the simulation consumes it in discrete 
> >>> dt sized chunks." seems like it will solve the problem, because I 
> >>> can then right tests for different amounts of times produced and 
> >>> consumed and make sure they are equal.
> >>>
> >>> brought to you by the letters A, V, and I and the number 47
> >>>
> >>>
> >>> On Sat, Feb 16, 2013 at 9:27 PM, sh [email protected]> wrote:
> >>> > Avi,
> >>> >
> >>> > the first option should work. When your test is ok for 30 fps, 
> >>> > you
> can
> >>> > safely assume that it will work for higher framerates.
> >>> >
> >>> > Best,
> >>> > Stefan
> >>> >
> >>> > Am 16.02.2013 20:07, schrieb Avi Kessner:
> >>> >> The first option won't work, because a 30 to 60 fps has to be
> assumed.
> >>> >>
> >>> >> That second option might be what is needed however. However, 
> >>> >> not the fixed time step but rather the "
> >>> >>
> >>> >> Free the physics" section. "So what we want is the best of both
> >>> >> worlds: a fixed delta time value for the simulation plus the 
> >>> >> ability to render at different framerates. These two things 
> >>> >> seem completely
> at
> >>> >> odds, and they are - unless we can find a way to decouple the 
> >>> >> simulation and rendering framerates."
> >>> >>
> >>> >>
> >>> >> brought to you by the letters A, V, and I and the number 47
> >>> >>
> >>> >>
> >>> >> On Sat, Feb 16, 2013 at 7:58 PM, sh [email protected]> wrote:
> >>> >>> I don't think this is very heisenbergish... :)
> >>> >>>
> >>> >>> The first option is to assume a sensible minimum framerate
(perhaps
> >>> 30
> >>> >>> FPS) and make that a specification for your game. (With 10 FPS it
> >>> >>> probably won't be fun anyway.)
> >>> >>> Then make the framerate a variable in your tests: physics.update(
> >>> >>> variableTimestepInMilliseconds );
> >>> >>> This makes the code testable for a given framerate. Of course
> higher
> >>> >>> framerates will deliver a small variation in the calculations, but
> >>> that
> >>> >>> shouldn't mess up the behaviour of the engine.
> >>> >>>
> >>> >>> The second option is a fixed timestep for your physics
calculations
> >>> as
> >>> >>> is described here:
> >>> http://gafferongames.com/game-physics/fix-your-timestep/
> >>> >>>
> >>> >>> Best,
> >>> >>> Stefan
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Am 16.02.2013 17:49, schrieb Avi Kessner:
> >>> >>>> Yes, the code is the same.
> >>> >>>>
> >>> >>>> See
> >>> >>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html from
> >>> >>>> http://news.ycombinator.com/item?id=4934855
> >>> >>>> for another example, where how accurate your timer or framerate
> >>> is can
> >>> >>>> affect the results of the tests.
> >>> >>>>
> >>> >>>> In the gravity example, if I run the equation as if the user has
> 10
> >>> frames
> >>> >>>> per second, I will get different results than if they run at 60
> >>> frames per
> >>> >>>> second.
> >>> >>>> Granted this is partially a problem with the code, but it should
> >>> still be
> >>> >>>> testable.
> >>> >>>>
> >>> >>>> Perhaps this is the Heisenberg of unit testing?
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> brought to you by the letters A, V, and I
> >>> >>>> and the number 47
> >>> >>>>
> >>> >>>>
> >>> >>>> On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
> >>> >>>> [email protected]>wrote:
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>> ------------------------------------
> >>> >>>
> >>> >>> Yahoo! Groups Links
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>> >> ------------------------------------
> >>> >>
> >>> >> Yahoo! Groups Links
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > ------------------------------------
> >>> >
> >>> > Yahoo! Groups Links
> >>> >
> >>> >
> >>> >
> >>>
> >>> brought to you by the letters A, V, and I
> >>> and the number 47
> >>>
> >>>
> >>> On Sat, Feb 16, 2013 at 9:27 PM, sh [email protected]> wrote:
> >>> > Avi,
> >>> >
> >>> > the first option should work. When your test is ok for 30 fps, you
> can
> >>> > safely assume that it will work for higher framerates.
> >>> >
> >>> > Best,
> >>> > Stefan
> >>> >
> >>> > Am 16.02.2013 20:07, schrieb Avi Kessner:
> >>> >> The first option won't work, because a 30 to 60 fps has to be
> assumed.
> >>> >>
> >>> >> That second option might be what is needed however. However, not
the
> >>> >> fixed time step but rather the "
> >>> >>
> >>> >> Free the physics" section. "So what we want is the best of both
> >>> >> worlds: a fixed delta time value for the simulation plus the
ability
> >>> >> to render at different framerates. These two things seem completely
> at
> >>> >> odds, and they are - unless we can find a way to decouple the
> >>> >> simulation and rendering framerates."
> >>> >>
> >>> >>
> >>> >> brought to you by the letters A, V, and I
> >>> >> and the number 47
> >>> >>
> >>> >>
> >>> >> On Sat, Feb 16, 2013 at 7:58 PM, sh [email protected]> wrote:
> >>> >>> I don't think this is very heisenbergish... :)
> >>> >>>
> >>> >>> The first option is to assume a sensible minimum framerate
(perhaps
> >>> 30
> >>> >>> FPS) and make that a specification for your game. (With 10 FPS it
> >>> >>> probably won't be fun anyway.)
> >>> >>> Then make the framerate a variable in your tests: physics.update(
> >>> >>> variableTimestepInMilliseconds );
> >>> >>> This makes the code testable for a given framerate. Of course
> higher
> >>> >>> framerates will deliver a small variation in the calculations, but
> >>> that
> >>> >>> shouldn't mess up the behaviour of the engine.
> >>> >>>
> >>> >>> The second option is a fixed timestep for your physics
calculations
> >>> as
> >>> >>> is described here:
> >>> http://gafferongames.com/game-physics/fix-your-timestep/
> >>> >>>
> >>> >>> Best,
> >>> >>> Stefan
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> Am 16.02.2013 17:49, schrieb Avi Kessner:
> >>> >>>> Yes, the code is the same.
> >>> >>>>
> >>> >>>> See
> >>> >>>> http://www.niksula.hut.fi/~hkankaan/Homepages/gravity.html from
> >>> >>>> http://news.ycombinator.com/item?id=4934855
> >>> >>>> for another example, where how accurate your timer or framerate
> >>> is can
> >>> >>>> affect the results of the tests.
> >>> >>>>
> >>> >>>> In the gravity example, if I run the equation as if the user has
> 10
> >>> frames
> >>> >>>> per second, I will get different results than if they run at 60
> >>> frames per
> >>> >>>> second.
> >>> >>>> Granted this is partially a problem with the code, but it should
> >>> still be
> >>> >>>> testable.
> >>> >>>>
> >>> >>>> Perhaps this is the Heisenberg of unit testing?
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> brought to you by the letters A, V, and I
> >>> >>>> and the number 47
> >>> >>>>
> >>> >>>>
> >>> >>>> On Fri, Feb 15, 2013 at 10:40 PM, George Dinwiddie
> >>> >>>> [email protected]>wrote:
> >>> >>>>
> >>> >>>
> >>> >>>
> >>> >>> ------------------------------------
> >>> >>>
> >>> >>> Yahoo! Groups Links
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>
> >>> >> ------------------------------------
> >>> >>
> >>> >> Yahoo! Groups Links
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > ------------------------------------
> >>> >
> >>> > Yahoo! Groups Links
> >>> >
> >>> >
> >>> >
> >>>
> >>>
> >>> ------------------------------------
> >>>
> >>> Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Edwin G. Castro
> >>
> >
> >
> >
> > --
> > Edwin G. Castro
> >
>
> --
> Edwin G. Castro
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links





------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/