I’m not going to list all the code I wrote in my posts anymore. It makes for pretty dull reading and you can download the code and read it at your own leisure. I’m sure the code is a lot more readable in your editor than on my blog anyway. I’ll just list a couple of interesting pieces and try to work out more of the concepts in my blog posts.
First of all here are the issues Sebastiaan wanted me to fix:
- Setting css styles can be done a bit cleaner.
- You can’t use arrow keys to move blocks. This is a problem on laptop keyboards without a numeric keypad.
The first three were easy to fix, I added a user story for the fourth issue. As this was the only user story that came from a potential user I put it right at the top of my backlog.
I want to start test-driving things, QUnit is a nice new toy that I want to start using. But unfortunately my code is a bit of a ball of mud. Luckily it’s not big so we can’t call it an antipattern yet. But it’s a good time to start separating some concerns.
I want to pull out pieces of functionality and put them in their own objects. Something like a model view presenter architecture would be nice with a TetrisView object to encapsulate drawing and reacting to user input, a TetrisGame object to handle game state and a TetrisPresenter to tie the two together.
This is what the tests look like,
I’m not yet 100% happy with them. I like how QUnit pushes you to a context-specification-ish test style. But it’s easy to assert too much in one test which is a bit of a test-smell to me.
I like how easy it is to build stub and mock objects in a dynamic language. I played a bit with these in tetrispresentertests.js if you want to have a look.
Tell me a story
The iteration backlog for this iteration (today) looks like this.
- The user can steer blocks with the arrow keys.
- Blocks can’t move outside of the playing field.
- When a block reaches the bottom of the playing field a new block should appear at the top
Now that I’ve got game logic, presentation logic and the view separated out nicely it’s easy to add some tests for these stories and implement them. I’ll just let the code speak for itself.