|
On Mon, Jan 21, 2013 at 6:47 PM, sh <shvfn@...> wrote: Dear Listables,
...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test of a simple behaviour of the completed system. Then I'd build just as little as possible to make the test pass. Matteo
|
I can heartily recommend reading "Growing Object Oriented Software: Guided by Tests". ( ). It walks you through the entire process, and unlike alot of literature doesn't shy away from some of the more "hairy" problems. The entire book is pretty much an answer to your question On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari <vaccari@...> wrote: **
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...> wrote:
Dear Listables,
... For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
[Non-text portions of this message have been removed]
-- Maybe she awoke to see the roommate's boyfriend swinging from the chandelier wearing a boar's head. Something which you, I, and everyone else would call "Tuesday", of course.
|
+1
Dave...
toggle quoted message
Show quoted text
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
<mailto:vaccari%40pobox.com>> wrote:
**
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@... <mailto:shvfn%40yahoo.de>> wrote:
Dear Listables,
... For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
|
+1 On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote: **
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote: **
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:
Dear Listables,
... For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
-- 础产谤补鏾蝉, 闯辞蝉耻� [Non-text portions of this message have been removed]
|
Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong, Tetris), what behaviour/class would you choose?
Michael,
thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!
Colin, Dave, Josue,
I'll try to get a copy. "Growing" software sounds a lot like the aspect I am interested in.
Thanks for the recommendation!
Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:
toggle quoted message
Show quoted text
+1
On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote:
**
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:
Dear Listables,
...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
|
The short answer is that yes, you do the next smallest step. I'm always amazed how nice it is when I completely 'follow the rules' the process exists cause its useful and works. On Jan 21, 2013 9:28 PM, "Josue Barbosa dos Santos" <josuesantos@...> wrote: +1
On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...>
wrote:
**
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software:
Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote: **
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:
Dear Listables,
... For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
[Non-text portions of this message have been removed]
--
础产谤补莽辞蝉,
闯辞蝉耻茅
------------------------------------
Yahoo! Groups Links
|
I'm not Matteo but I would either first test a score, or for tetris a line
match, or for pong the angle of a bounce.
toggle quoted message
Show quoted text
On Jan 21, 2013 10:44 PM, "sh" <shvfn@...> wrote: Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
Michael,
thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!
Colin, Dave, Josue,
I'll try to get a copy. "Growing" software sounds a lot like the aspect
I am interested in.
Thanks for the recommendation!
Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:
+1
On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote:
**
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire
book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:
Dear Listables,
...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
------------------------------------
Yahoo! Groups Links
|
Ummm.. for Tetris, I could write tests (one by one) to:
- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X above, next
cycle, Y and X are in the same position
- etc...
It's not full TDD, but many test on a simple isometric engine JavaScript
(I skipped the test at browser side, I should learn how to do them, maybe
using QUnit or Jazmine?)
See the commits, I usually commit test (one by one))
A full TDD sample, chess, see the commit
Angel "Java" Lopez
@ajlopez
github:ajlopez
toggle quoted message
Show quoted text
On Mon, Jan 21, 2013 at 5:06 PM, sh <shvfn@...> wrote: Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
Michael,
thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!
Colin, Dave, Josue,
I'll try to get a copy. "Growing" software sounds a lot like the aspect
I am interested in.
Thanks for the recommendation!
Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:
+1
On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney <daverooneyca@...> wrote:
**
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of literature
doesn't shy away from some of the more "hairy" problems. The entire
book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari vaccari@...
wrote:
**
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
wrote:
Dear Listables,
...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the test
of a simple behaviour of the completed system. Then I'd build just as
little as possible to make the test pass.
Matteo
------------------------------------
Yahoo! Groups Links
|
Hi � On Jan 21, 2013, at 3:06 PM, sh <shvfn@...> wrote: hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose? For a look at one what man is trying see the Codea articles on my web site. I'm not very far along yet, but they'll show you the way I'm thinking at the beginning. Questions welcome, they'll help me figure out what to do and say next. Ron Jeffries www.XProgramming.com It's true hard work never killed anybody, but I figure, why take the chance? -- Ronald Reagan [Non-text portions of this message have been removed]
|
Avi,
ok, I see. So you would start with something more "practical" than the
concept of class Engine?
This is something I noticed when I read about behaviour driven
development, that I had problems to define a "behaviour" of my game. I
could have immediately started coding the usual bunch of classes, but to
sit in front of an empty file and think about a "behaviour" to start
with... wasn't exactly easy. :)
I guess that's part of my learning curve.
Thank you!
Angel & Ron,
thanks for the examples! That's a good reference for me (see above :) ).
Corey,
the book is on my list now! Thanks!
Bill,
I like you're idea of testing the "stress point".
I guess, I simply have to "do TDD", gain more experience and be open to
what the tests tell me...
Charlie,
the "programming propeller" is a nice image... :)
And "tension" describes my initial feeling towards TDD quite good. On
the one hand I'm fascinated by the idea of an "emerging design" that is
always secured by tests; on the other hand my brain is simply not
convinced, that this will work out. I am really surprised, how hard it
is for me to let these thoughts rest aside.
Thank you for describing your mindset, very helpful.
Thank you all for the nice welcome!
:)
Am 21.01.2013 21:50, schrieb Avi Kessner:
toggle quoted message
Show quoted text
I'm not Matteo but I would either first test a score, or for tetris a line
match, or for pong the angle of a bounce.
On Jan 21, 2013 10:44 PM, "sh" shvfn@...
<mailto:shvfn%40yahoo.de>> wrote:
Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
Michael,
thank you for this insight from your coders life.
Perhaps I do worry to much. I question the method before even starting.
OK, I'll try!
Colin, Dave, Josue,
I'll try to get a copy. "Growing" software sounds a lot like the aspect
I am interested in.
Thanks for the recommendation!
Am 21.01.2013 20:28, schrieb Josue Barbosa dos Santos:
+1
On Mon, Jan 21, 2013 at 5:27 PM, Dave Rooney daverooneyca@... <mailto:daverooneyca%40gmail.com>>
wrote:
**
+1
Dave...
On 13-01-21 2:20 PM, Colin Vipurs wrote:
I can heartily recommend reading "Growing Object Oriented Software: Guided
by Tests". (
).
It walks you through the entire process, and unlike alot of
literature
doesn't shy away from some of the more "hairy" problems. The entire
book
is pretty much an answer to your question
On Mon, Jan 21, 2013 at 6:05 PM, Matteo Vaccari
vaccari@... <mailto:vaccari%40pobox.com>
wrote:
**
On Mon, Jan 21, 2013 at 6:47 PM, sh shvfn@...
<mailto:shvfn%40yahoo.de>
wrote:
Dear Listables,
...
For example I expect to end up with
- an engine class,
- a scene or context
- a renderer,
- an event- or signal/slot-system,
- an entity/component system
- etc, etc.
When I now start to write my first tests, I guess I start with the
engine class.
... I would not start with that. I would more likely start with the
test
of a simple behaviour of the completed system. Then I'd build
just as
little as possible to make the test pass.
Matteo
------------------------------------
Yahoo! Groups Links
|
For Tetris I've done this:
I first focused on getting 1x1 blocks falling, then moved to rotating multi-block shapes, and merged those together to get falling multi-block shapes. And it's in a tutorial form, so that others can follow the same steps to learn TDD.
Angel Java Lopez wrote on 21.1.2013 23:40:
toggle quoted message
Show quoted text
Ummm.. for Tetris, I could write tests (one by one) to:
- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X above, next
cycle, Y and X are in the same position
- etc...
--
Esko Luontola
www.orfjackal.net
|
On Mon, Jan 21, 2013 at 9:06 PM, sh <shvfn@...> wrote: Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
Well, for instance in Tetris you could list a few simple behaviours: - a block falls - a block stops when it hits the bottom - a block stops when it hits another block - the player can rotate the block - the player can slide the block left or right - ... Then you choose one and write a test for it. Matteo
|
On Tue, Jan 22, 2013 at 1:39 PM, Matteo Vaccari <vaccari@...> wrote:
On Mon, Jan 21, 2013 at 9:06 PM, sh <shvfn@...> wrote:
Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
Well, for instance in Tetris you could list a few simple behaviours:
- a block falls
- a block stops when it hits the bottom
- a block stops when it hits another block
- the player can rotate the block
- the player can slide the block left or right
- ...
Then you choose one and write a test for it.
Sometimes the test you choose turns out to be too difficult... in the sense that it takes more than a few minutes to make it pass. This is where the fun begins :) you can comment the current test and try to write a smaller test that you hope will make it easier to pass the original one. You can try to see the behaviour as a composition of simpler behaviours. You can try to simplify the problem by making it more general. There is a great example in the TDD book by Kent Beck. He says (quoting from memory) "when I have to implement a TCP server, I start by writing a test for a server that echoes whatever you send to it [and this is the simplification part]. Then I extract the part that reads a string and returns the same string in an object. Now the TCP server uses that object to decide what to answer." So now he can continue to TDD the logic of the server in a plain object that does not know about sockets. The problem has been generalized *and* made simpler at the same time :-) Matteo
|
On Mon, Jan 21, 2013 at 3:06 PM, sh <shvfn@...> wrote: Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
I'm not Matteo, but you usually have a number of choices. Joseph Leddy, Kent Beck, & I wrote this article, "Slicing Functionality: Alternate Paths" to talk about exploring some of them: Different approaches can lead you toward different solutions to the same overall problem. --Bill -- Bill Wake Industrial Logic, Inc. @IndustrialLogic Coaching | Training | Assessment | eLearning
|
I just saw this blog entry today, and I think it might help you understand and answer your questions. It might also help you get past your mental block (which I believe we all have had at one point or another) brought to you by the letters A, V, and I and the number 47 On Tue, Jan 22, 2013 at 3:18 PM, Bill Wake <william.wake@...> wrote: **
On Mon, Jan 21, 2013 at 3:06 PM, sh shvfn@...> wrote:
Matteo,
hm, I'm not sure I understand. When you imagine a simple game (Pong,
Tetris), what behaviour/class would you choose?
I'm not Matteo, but you usually have a number of choices. Joseph Leddy,
Kent Beck, & I wrote this article, "Slicing Functionality: Alternate Paths"
to talk about exploring some of them:
Different approaches can lead you toward different solutions to the same
overall problem.
--Bill
--
Bill Wake
Industrial Logic, Inc. @IndustrialLogic
Coaching | Training | Assessment | eLearning
[Non-text portions of this message have been removed]
|
Esko,
that looks like a great tutorial to get going. I also read your
article about "three styles of naming tests". Very good read. I
realized, that I am used to implementation-style naming and -thinking
and I guess, that is also the reason, why I had such a hard time finding
the initial behaviours for my game-project. Instead of thinking about
something like "player ship should accelerate when the 'forward-key' is
pressed" I started with "Engine should initialize Renderer on startup".
That's quite a different 'story'. :)
Somehow I automatically think about several different classes/systems,
when I think about coding "move a tetris-block". I start to understand
now, that I have to forget this to get going.
Matteo,
thanks for explaining your approach! That's really helpful.
Ron, Bill and Avi,
thank you for the links and articles! I'm slowly digesting the different
inputs and views you all offered to me and that is definitely helping to
get a better understanding.
It seems, it's not a bad idea to start TDD with a game. Now I need to
practice! :)
Best,
Stefan
Am 21.01.2013 23:51, schrieb Esko Luontola:
toggle quoted message
Show quoted text
For Tetris I've done this:
I first focused on getting 1x1 blocks falling, then moved to rotating
multi-block shapes, and merged those together to get falling multi-block
shapes. And it's in a tutorial form, so that others can follow the same
steps to learn TDD.
Angel Java Lopez wrote on 21.1.2013 23:40:
Ummm.. for Tetris, I could write tests (one by one) to:
- Give me an empty "board"
- Put a Piece X at position x,y, get its position
- Put a Piece X at position x,y, run a cycle, get its new position
- Put a Piece Y at position x1,y1, Put Piece X at positions ... all
invalids because they are on Y
- Put a Piece Y at position x1,y1, touching floor, put Piece X above, next
cycle, Y and X are in the same position
- etc...
--
Esko Luontola
www.orfjackal.net
|
