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
