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 <egcastr@...> 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 <egcastr@...> 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 <akessner@...> 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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>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]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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 <egcastr@...> 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 <akessner@...> 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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
--
Edwin G. Castro
-- Edwin G. Castro [Non-text portions of this message have been removed]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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 <akessner@...> 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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
-- Edwin G. Castro [Non-text portions of this message have been removed]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi, I have to agree with Stefan. If I assume that the calculations do not work the same for different framerates, then that would imply that I need to write custom code to alter the calculations for said framerates. That implies that I need tests for varying framerates. I can still treat the system as a blackbox with inputs that include the framerate. The output (in the examples the appropriate output sounds like position) would then vary given the framerate but I would expect the same results given the same inputs. Such a difference in behavior driven by framerate could then be designed driven by the tests. All that said, I really don't expect the framerate to change the calculations. You enter your inputs (initial position, velocity, acceleration, external forces, etc, and number of ticks) and you should be able to calculate the outputs consistently (final position, velocity, acceleration, etc.) -- Edwin On Sat, Feb 16, 2013 at 11:27 AM, sh <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>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 <shvfn@...> 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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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:
toggle quoted message
Show quoted text
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 <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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
toggle quoted message
Show quoted text
On Sat, Feb 16, 2013 at 7:58 PM, sh <shvfn@...> 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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
Yes, the code is the same.
See
from
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
<lists@...>wrote:
------------------------------------
Yahoo! Groups Links
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi, On 2/16/13 11:49 AM, Avi Kessner wrote: Yes, the code is the same.
See
from
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? It sounds like a typical problem of not abstracting the external source of timing. You should be able to calculate into the future without being tied to the system clock. - George
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
<lists@...>wrote:
**
Avi,
On 2/15/13 4:24 AM, Avi Kessner wrote:
Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the
screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot
where the penguin will land at the end of the run. However, the marker
needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict
where the penguin will land, and place a graphic exactly there before all
the animations for the penguin flying through the air are done. Is the calculation of the penguin's movement and the calculation of the
marker position both done by the unit under test?
- George
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD)
It seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm missing
to make it work. My problem with putting in values such as 0 or 1 is that
while I should get 0 distance with an input of 0, that doesn't actually
help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij wouter@...
wrote:
**
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also
had a
case where we were calculating some complex formulas and I couldn't get
an
exact result predicted, simply because the system was meant to be able
to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to
accept
approximate values, within a given range. So the expected outcome would
for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the
seed
used to generate random values that were used in the calculations, which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...>
wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...> wrote:
Even when the math is complicated, there should be inputs where the results
are easy to hand compute. For example, where the inputs are combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to drive
development of properly structured code.
I would depend on customer-level tests to see if the computations are
properly supporting whatever "business" functionality the system is
supposed to deliver. If wrong answers still allows the user to do
what
they need to do, then maybe the fancy formulas are overkill anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...>
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact with
each
other The math is too complicated for me to resolve easily. These
formulas are calculated based on time. (For example, an elastic
tween
formula)
I need to write a series of functions which predict what the steps
of
the
formula will be. (How many timer ticks will it take to get to point
A?)
This is something that I feel can have tests, and needs tests. But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
------------------------------------
Yahoo! Groups Links
--
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------
------------------------------------
Yahoo! Groups Links
-- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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:
Best,
Stefan
Am 16.02.2013 17:49, schrieb Avi Kessner:
toggle quoted message
Show quoted text
Yes, the code is the same.
See
from
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
<lists@...>wrote:
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Yes, the code is the same. See from 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 <lists@...>wrote: **
Avi,
On 2/15/13 4:24 AM, Avi Kessner wrote:
Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the
screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot
where the penguin will land at the end of the run. However, the marker
needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict
where the penguin will land, and place a graphic exactly there before all
the animations for the penguin flying through the air are done. Is the calculation of the penguin's movement and the calculation of the
marker position both done by the unit under test?
- George
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD)
It seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm missing
to make it work. My problem with putting in values such as 0 or 1 is that
while I should get 0 distance with an input of 0, that doesn't actually
help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij wouter@...
wrote:
**
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also
had a
case where we were calculating some complex formulas and I couldn't get
an
exact result predicted, simply because the system was meant to be able
to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to
accept
approximate values, within a given range. So the expected outcome would
for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the
seed
used to generate random values that were used in the calculations, which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...>
wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...> wrote:
Even when the math is complicated, there should be inputs where the results
are easy to hand compute. For example, where the inputs are combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to drive
development of properly structured code.
I would depend on customer-level tests to see if the computations are
properly supporting whatever "business" functionality the system is
supposed to deliver. If wrong answers still allows the user to do
what
they need to do, then maybe the fancy formulas are overkill anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...>
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact with
each
other The math is too complicated for me to resolve easily. These
formulas are calculated based on time. (For example, an elastic
tween
formula)
I need to write a series of functions which predict what the steps
of
the
formula will be. (How many timer ticks will it take to get to point
A?)
This is something that I feel can have tests, and needs tests. But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
--
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------
[Non-text portions of this message have been removed]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi, On 2/15/13 4:24 AM, Avi Kessner wrote: Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the
screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot
where the penguin will land at the end of the run. However, the marker
needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict
where the penguin will land, and place a graphic exactly there before all
the animations for the penguin flying through the air are done. Is the calculation of the penguin's movement and the calculation of the marker position both done by the unit under test? - George
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD)
It seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm missing
to make it work. My problem with putting in values such as 0 or 1 is that
while I should get 0 distance with an input of 0, that doesn't actually
help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij <wouter@...>wrote:
**
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also had a
case where we were calculating some complex formulas and I couldn't get an
exact result predicted, simply because the system was meant to be able to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to accept
approximate values, within a given range. So the expected outcome would for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the seed
used to generate random values that were used in the calculations, which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...> wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...> wrote:
Even when the math is complicated, there should be inputs where the results
are easy to hand compute. For example, where the inputs are combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to drive
development of properly structured code.
I would depend on customer-level tests to see if the computations are
properly supporting whatever "business" functionality the system is
supposed to deliver. If wrong answers still allows the user to do
what
they need to do, then maybe the fancy formulas are overkill anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...>
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact with
each
other The math is too complicated for me to resolve easily. These
formulas are calculated based on time. (For example, an elastic
tween
formula)
I need to write a series of functions which predict what the steps
of
the
formula will be. (How many timer ticks will it take to get to point
A?)
This is something that I feel can have tests, and needs tests. But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
------------------------------------
Yahoo! Groups Links
-- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi,
Have you considered refactoring so that the algorithm is extracted?
You could then inject a very simple, predictable one back in for your tests.
That still leaves the real, complicated algorithm - but you aren't testing that - just using it.
(If I understood correctly).
At least if you extract the algorithm, you are separating the concerns.
John D.
toggle quoted message
Show quoted text
-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Avi Kessner
Sent: 15 February 2013 15:49
To: testdrivendevelopment@...
Subject: 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.
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi,
I think you are expecting something unrealistic from TDD.
TDDing only facilitates 2 things:
1. Verifying that the code does what the programmer thinks the code should
do.
2. Growing the code in a way that makes the code testable, expressive and
well-factored.
TDD (and unit tests in general) will NOT verify that what the programmer
thinks the code should do actually solves the problem correctly. That is
why we have customers, customer tests and feedback on frequent deliveries
of working software.
If you do not have any idea how to solve the problem, TDD will not
magically lead you to a solution. If you do have an idea, then TDD will
only help you verify that you implemented YOUR idea faithfully and that the
code is well structured.
------------------------------------------------------------------------------------------
I also agree with what I think that others have said about your specific
problem: The engine should be responsible for this functionality, not some
independently developed code. The engine should be able to "predict" what
is would do by running its own functions to simulate what it would do. Why
reinvent the algorithms that the engine already implements? Even if a
faster, less accurate prediction is required than simulating the full
engine algorithm, the engine code and its developers will have a much
better start on seeing what can be left out and still return a good enough
estimation.
Steven Gordon
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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
|
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
toggle quoted message
Show quoted text
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
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
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
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Avi47,
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!
In TDD we are often just focusing on edge cases - but you are exploring a whole field of possibilities.
I wonder if the field varies smoothly? In that case you might be able to interpolate the predicted outcomes?
(Somewhere between a hard hit and a medium hit the penguin bounces less and goes half way...)
John D.
toggle quoted message
Show quoted text
-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Avi Kessner
Sent: 15 February 2013 10:25
To: testdrivendevelopment@...
Subject: Re: [TDD] How do you write tests if you aren't sure what the result should be?
Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot where the penguin will land at the end of the run. However, the marker needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict where the penguin will land, and place a graphic exactly there before all the animations for the penguin flying through the air are done.
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.
Ideally however, I don't just want to have acceptance tests that it works, I also want my tests to help me develop the solution. (aka TDD) It seems to me that this should be possible (cause it's just math being done over some variable data etc) but I can't figure out what I'm missing to make it work. My problem with putting in values such as 0 or 1 is that while I should get 0 distance with an input of 0, that doesn't actually help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I and the number 47
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
It still seems to me that you're trying to use TDD to derive the equations.
The programming departments are sometimes called R&D departments.
The last D is the same last D in TDD.
Research (and you are trying to derive the formulae here, not just use them)
can be guided by a test to the extent that you will know when you have
researched a GOOD ENOUGH solution.
Consider the Rubik cube. Can you TDD a program to solve it? If you do not
have an algorithm to implement, you will need to enumerate all possible cube
scenarios and figure out how to solve each one. You could hard code each
solution, but if you wanted a more elegant solution you will need to step
away from the keyboard, and really UNDERSTAND what the problem is.
I think that this is your problem right now. TDD is not a substitute for
understanding the problem domain. You cannot hope to start doing TDD and
hope things will sort out. TDD will ensure that your implementation of the
solution will be correct and complete and that your design is of a high
quality. It will not TEACH you what the domain is.
Sorry :-(
Amir
toggle quoted message
Show quoted text
-----Original Message----- From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Avi Kessner Sent: Friday, February 15, 2013 6:31 AM To: testdrivendevelopment@... Subject: Re: [TDD] How do you write tests if you aren't sure what the result should be? Hi Angel, Thanks for what you wrote. However, I don't understand the last section. I think it is the most important part! "We wrote many test files, and a test that loads a file, run it, and compare the final state (In many projects, I use JSON files (or urggg.... XML ;-), directly, to not write a DSL parser). The internal implementation emerged for this evolutive approach, with TDD. As usual, refactor, back of the envelope design, discussions, etc.. Meanwhile, an spike about rendering the game status." How did you get the implementation to evolve from the multiple test files? How did you write the test files? What is "an spike about rendering game status"? brought to you by the letters A, V, and I and the number 47 On Fri, Feb 15, 2013 at 12:11 PM, Angel Java Lopez <ajlopez2000@...>wrote: **
Hi people!
Ah! Thanks for the detail, Avi. I have more context. Ok, short
phrases, English is not in my expertise ;-)
If I were to implement something like you describe (I had some similar
projects):
- I should separate the rendering of the game behavior. My tests will
have no rendering test, at least at first iterations
- It should be like coding MVC web applications: you code and develop
the controller using TDD without any view, yet.
- I should test the penguin movement. Penguin at X, run one cycle,
then Penguin at X+dX
- I should test the collision
- I should test the bounce angle
- etc....
Then, when the setting of the test start to be complicated, in one
project, we wrote a DSL language, like:
penguin at x,y
penguin direction a
penguin velocity v
brick at x2,y2
run 3 cycle
then
penguin at x3,y3
penguin direction a'
penguin velocity v'
We wrote many test files, and a test that loads a file, run it, and
compare the final state (In many projects, I use JSON files (or
urggg.... XML ;-), directly, to not write a DSL parser).
The internal implementation emerged for this evolutive approach, with TDD.
As usual, refactor, back of the envelope design, discussions, etc..
Meanwhile, an spike about rendering the game status.
Angel "Java" Lopez
@ajlopez
gh:ajlopez
On Fri, Feb 15, 2013 at 6:24 AM, Avi Kessner akessner@...> wrote:
Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across
the screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the
spot where the penguin will land at the end of the run. However, the
marker needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to
predict where the penguin will land, and place a graphic exactly
there before all the animations for the penguin flying through the air are done.
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD) It
seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm
missing to make it work. My problem with putting in values such as 0
or 1 is that while I should get 0 distance with an input of 0, that
doesn't actually help me solve the problem. What do I do for inputs
greater than zero?
brought to you by the letters A, V, and I and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij wouter@...
wrote: **
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also
had a
case where we were calculating some complex formulas and I couldn't
get an
exact result predicted, simply because the system was meant to be able to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to accept
approximate values, within a given range. So the expected outcome
would for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the seed
used to generate random values that were used in the calculations,
which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would
you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...>
wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...>
wrote:
Even when the math is complicated, there should be inputs where
the
results
are easy to hand compute. For example, where the inputs are combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to
drive
development of properly structured code.
I would depend on customer-level tests to see if the
computations are
properly supporting whatever "business" functionality the system
is
supposed to deliver. If wrong answers still allows the user to
do what
they need to do, then maybe the fancy formulas are overkill
anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a
snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact
with
each
other The math is too complicated for me to resolve easily.
These
formulas are calculated based on time. (For example, an
elastic tween
formula)
I need to write a series of functions which predict what the
steps
of
the
formula will be. (How many timer ticks will it take to get to
point
A?)
This is something that I feel can have tests, and needs tests.
But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I
write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
------------------------------------
Yahoo! Groups Links
------------------------------------ Yahoo! Groups Links
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Hi Angel,
Thanks for what you wrote.
However, I don't understand the last section. I think it is the most
important part!
"We wrote many test files, and a test that loads a file, run it, and compare
the final state
(In many projects, I use JSON files (or urggg.... XML ;-), directly, to not
write a DSL parser).
The internal implementation emerged for this evolutive approach, with TDD.
As usual, refactor, back of the envelope design, discussions, etc..
Meanwhile, an spike about rendering the game status."
How did you get the implementation to evolve from the multiple test files?
How did you write the test files? What is "an spike about rendering game
status"?
brought to you by the letters A, V, and I
and the number 47
toggle quoted message
Show quoted text
On Fri, Feb 15, 2013 at 12:11 PM, Angel Java Lopez <ajlopez2000@...>wrote: **
Hi people!
Ah! Thanks for the detail, Avi. I have more context. Ok, short phrases,
English is not in my expertise ;-)
If I were to implement something like you describe (I had some similar
projects):
- I should separate the rendering of the game behavior. My tests will have
no rendering test, at least at first iterations
- It should be like coding MVC web applications: you code and develop the
controller using TDD without any view, yet.
- I should test the penguin movement. Penguin at X, run one cycle, then
Penguin at X+dX
- I should test the collision
- I should test the bounce angle
- etc....
Then, when the setting of the test start to be complicated, in one project,
we wrote a DSL language, like:
penguin at x,y
penguin direction a
penguin velocity v
brick at x2,y2
run 3 cycle
then
penguin at x3,y3
penguin direction a'
penguin velocity v'
We wrote many test files, and a test that loads a file, run it, and compare
the final state
(In many projects, I use JSON files (or urggg.... XML ;-), directly, to not
write a DSL parser).
The internal implementation emerged for this evolutive approach, with TDD.
As usual, refactor, back of the envelope design, discussions, etc..
Meanwhile, an spike about rendering the game status.
Angel "Java" Lopez
@ajlopez
gh:ajlopez
On Fri, Feb 15, 2013 at 6:24 AM, Avi Kessner akessner@...> wrote:
Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the
screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot
where the penguin will land at the end of the run. However, the marker
needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict
where the penguin will land, and place a graphic exactly there before all
the animations for the penguin flying through the air are done.
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD)
It seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm missing
to make it work. My problem with putting in values such as 0 or 1 is that
while I should get 0 distance with an input of 0, that doesn't actually
help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij wouter@...
wrote: **
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also
had a
case where we were calculating some complex formulas and I couldn't get an
exact result predicted, simply because the system was meant to be able
to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to accept
approximate values, within a given range. So the expected outcome would for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the
seed
used to generate random values that were used in the calculations,
which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would
you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...>
wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...>
wrote:
Even when the math is complicated, there should be inputs where
the
results
are easy to hand compute. For example, where the inputs are combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to
drive
development of properly structured code.
I would depend on customer-level tests to see if the computations
are
properly supporting whatever "business" functionality the system
is
supposed to deliver. If wrong answers still allows the user to do
what
they need to do, then maybe the fancy formulas are overkill
anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a
snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact
with
each
other The math is too complicated for me to resolve easily.
These
formulas are calculated based on time. (For example, an elastic
tween
formula)
I need to write a series of functions which predict what the
steps
of
the
formula will be. (How many timer ticks will it take to get to
point
A?)
This is something that I feel can have tests, and needs tests.
But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I
write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
------------------------------------
Yahoo! Groups Links
[Non-text portions of this message have been removed]
|
Re: [TDD] How do you write tests if you aren't sure what the result should be?
Hi people!
Ah! Thanks for the detail, Avi. I have more context. Ok, short phrases,
English is not in my expertise ;-)
If I were to implement something like you describe (I had some similar
projects):
- I should separate the rendering of the game behavior. My tests will have
no rendering test, at least at first iterations
- It should be like coding MVC web applications: you code and develop the
controller using TDD without any view, yet.
- I should test the penguin movement. Penguin at X, run one cycle, then
Penguin at X+dX
- I should test the collision
- I should test the bounce angle
- etc....
Then, when the setting of the test start to be complicated, in one project,
we wrote a DSL language, like:
penguin at x,y
penguin direction a
penguin velocity v
brick at x2,y2
run 3 cycle
then
penguin at x3,y3
penguin direction a'
penguin velocity v'
We wrote many test files, and a test that loads a file, run it, and compare
the final state
(In many projects, I use JSON files (or urggg.... XML ;-), directly, to not
write a DSL parser).
The internal implementation emerged for this evolutive approach, with TDD.
As usual, refactor, back of the envelope design, discussions, etc..
Meanwhile, an spike about rendering the game status.
Angel "Java" Lopez
@ajlopez
gh:ajlopez
toggle quoted message
Show quoted text
On Fri, Feb 15, 2013 at 6:24 AM, Avi Kessner <akessner@...> wrote: Thank you for your help and suggestions so far.
My actual use case is a bit boring, but I found a more fun analogy.
Say you were asked to make a change to a game called Yetti Sport.
The object of the game is that you hit a penguin and it flies across the
screen until it stops bouncing or getting blown up by mines.
The task required is that you place a marker or some graphic on the spot
where the penguin will land at the end of the run. However, the marker
needs to be placed before the spot becomes visible.
This means that you need to use the current state of the game to predict
where the penguin will land, and place a graphic exactly there before all
the animations for the penguin flying through the air are done.
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.
Ideally however, I don't just want to have acceptance tests that it works,
I also want my tests to help me develop the solution. (aka TDD)
It seems to me that this should be possible (cause it's just math being
done over some variable data etc) but I can't figure out what I'm missing
to make it work. My problem with putting in values such as 0 or 1 is that
while I should get 0 distance with an input of 0, that doesn't actually
help me solve the problem. What do I do for inputs greater than zero?
brought to you by the letters A, V, and I
and the number 47
On Fri, Feb 15, 2013 at 1:23 AM, Wouter Lagerweij <wouter@...
wrote: **
Hi Avi,
I'm not sure whether this is applicable to your situation, but I also had a
case where we were calculating some complex formulas and I couldn't get an
exact result predicted, simply because the system was meant to be able to
calculate those results with more precision than was possible before.
In that situation, we were able to define our (acceptance) tests to accept
approximate values, within a given range. So the expected outcome would for
instance be 0.546 +/- 0.5%
We also had to control some of the inputs to the system, such as the seed
used to generate random values that were used in the calculations, which
would normally change with time.
Is that something that might work in your circumstances?
Wouter
On Thu, Feb 14, 2013 at 5:31 PM, Charlie Poole charliepoole@...
wrote:
Hi Avi,
If you had to test your work only by direct observation, what would you
look for?
Charlie
On Thu, Feb 14, 2013 at 7:21 AM, Avi Kessner akessner@...> wrote:
**
Ill write more later when I'm at my desk, but the use case here is matching
and predicting animations
On Feb 14, 2013 5:15 PM, "Steven Gordon" sgordonphd@...>
wrote:
Even when the math is complicated, there should be inputs where the results
are easy to hand compute. For example, where the inputs are
combinations
of 0s, 1s, -1s, etc. Those trivial cases should be enough to drive
development of properly structured code.
I would depend on customer-level tests to see if the computations
are
properly supporting whatever "business" functionality the system is
supposed to deliver. If wrong answers still allows the user to do
what
they need to do, then maybe the fancy formulas are overkill anyway.
SteveG
On Thu, Feb 14, 2013 at 12:24 AM, Avi Kessner akessner@...>
wrote:
**
Hi, I have a simple question.
I've been developing my program with TDD however I have hit a
snag
and
I'm
not sure how to continue.
We have some complicated mathematical formulas that interact with
each
other The math is too complicated for me to resolve easily. These
formulas are calculated based on time. (For example, an elastic
tween
formula)
I need to write a series of functions which predict what the
steps
of
the
formula will be. (How many timer ticks will it take to get to
point
A?)
This is something that I feel can have tests, and needs tests.
But
I
have
no idea what to check or how to know if the test is correct.
My actual question is a meta-question by the way. How do I write
tests
when I don't know what the results should be, but I know the
computer
needs
to get the "correct" result?
Thanks.
brought to you by the letters A, V, and I
and the number 47
------------------------------------
Yahoo! Groups Links
------------------------------------
Yahoo! Groups Links
--
Wouter Lagerweij | wouter@...
| @wouterla !/wouterla>
------------------------------------
Yahoo! Groups Links
|
