Skip to main content

JavaScript Tetris part II – some tests

Here’s a little update on the JavaScript front. I’ve been busy working on Tetris this weekend. Lots of new stuff to learn and lots to do. First of all I got a list of issues from Sebastiaan Janssen that needed fixing (thanks, that was exactly the kind of feedback I was hoping for). I’ve been playing around with unit testing JavaScript with QUnit. Of course my existing code wasn’t really testable so I had to refactor things a bit too. And I tried to test-drive a couple of small stories.

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:

  • I’m using the JavaScript const keyword but IE doesn’t support this.
  • Setting css styles can be done a bit cleaner.
  • JavaScript in the .html file
  • 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.

Refactoring

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,

   1: module('tetrisGame');
   2:  
   3: test('when initializing', function() {
   4:     var game = new TetrisGame();
   5:     
   6:     equals(18, game.yPos, 'block starts on the right y position.');
   7:     equals(5, game.xPos, 'block starts on the right x position.');
   8: });
   9:  
  10: test('when running the game loop', function() {
  11:     var game = new TetrisGame();
  12:     
  13:     game.gameLoop();
  14:     
  15:     equals(17, game.yPos, 'block moves down.');
  16:     equals(5, game.xPos, 'block stays in the same horizontal position.')
  17: });
  18:  
  19: test('when moving left', function() {
  20:     var game = new TetrisGame();
  21:     
  22:     game.moveLeft();
  23:     
  24:     equals(4, game.xPos, 'block moves left');
  25:     equals(18, game.yPos, 'block stays at the same height');
  26: });
  27:  
  28: // etc...

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.


tetris0.02.rar (12.36 kb)

Comments

Popular posts from this blog

Marshalling strings with StringBuilder

The dotNet framework is pretty smart when it comes to marshalling managed to unmanaged datatypes for PInvoke calls. When you want to pass a Guid from the managed to the unmanaged world the framework knows how to transform the .Net Guid structure to a Windows GUID without you even asking for it.

Agile architecture, embrace change by reducing complexity

Software development can sometimes be very counterintuitive. For example, when people started building larger software systems halfway through the last century one of the things they discovered was that changing existing software is often far more difficult and error prone than building new software. Most developers rediscover this somewhere in their first year of being a professional developer. They start out with a new project and as time goes by changes start taking more and more time, this can be very hard to explain to a client and usually we don’t until we get completely stuck and tell the client we need to start from scratch. I think this practice has been responsible for most of the bad reputation software development has.

Square One available on the Android market

This is just a short post to let you know that a first version of the Android app I’ve been working on for the last couple of weeks is available on the Android market. The app is called Square One and it’s a simple bassline synthesizer. It’s free so try it out and let me know what you think of it, but be prepared it’s still an early version. I hope to add more features in the next few months and maybe build something that can be used to create real music.The lower part of the screen contains the sequencer controls that can be used to program your own bass lines. On the left is a four by four grid of buttons where you can select a step in the sequence. On the right you can select the note to be played on that step. When you’re done you can press Start and the sequence starts playing. The knobs on the top can be used to control a couple of parameters from the synthesizer engine that creates the sound. You can control the cutoff frequency and resonance of the low-pass filter, attack and …