Boulder Blaster - Adding tests

Lovely lovely tests.

In my previous post about Boulder Blaster, I mentioned that I wanted to add tests to the code base. Tests that will check that my code behaves as I want it to. They are something that I, ever since I first learned Test Driven Development (TDD), always want to use with my projects. I find them great for several reasons, for example:

• Makes it a lot easier to rewrite, remove and add to the code and still be certain that all the parts works as intended. If written correctly, this will even apply the foundation of a project. Making it so I don’t need to think about all possible features from the start. I can start coding one feature at the time and not worry to much about making a good foundation for future ideas.
• Helps when one is working on the code for short periods with large breaks in between (which is very usual for my hobby projects). They give one less need to remember how all the parts work by themselves and together. If I document the intended behavior with tests, they will tell me (angrily) if I forgot about something.
• Can be used as a To-Do. Sometimes I write a bunch of failing tests a list of all the things that needs to be fixed.

I haven’t been able to embrace true TDD practices while writing this game. I’m specifically referring to the practice of writing the tests first. So far I have written the game code first and the tests afterwards. As long as I’m a novice with JavaScript and game development that will probably continue.

Framework for testing

There is a bunch of frameworks for testing JavaScript. I had no idea how to choose one so I started to look into one that had a name I liked, Jasmine. It looked like it did everything I could think of needing and more. I took a quick check on some other frameworks, but didn’t see any reason choice them over Jasmine.

One thing that made me stick with my first choice, was that Jasmine works with Node.js. Someday I would like to learn it and not having to learn a totally different test framework for that too will be nice.

(Also before I committed to Jasmine, I did a quick check to see if it was possible to integrate with Jenkins. Which it was. The reason I wanted to know that, is that we use Jenkins at work. It is nice to learn something I some day can bring into my work projects as well.)

Jasmine is different from what I’m used to when working with C# / Nunit, but it does the job I need it to do.

Code changes

I have uploaded the code to GitHub to make it easier to present all the versions and various parts. To easily compare the two version of the project use these two links:

• The version I talked about in previous blog post
• The version I talking about in this blog post.

(And if you want the view the absolute latest version click here.)

(Please note that I have not included the files for Pixi or Jasmine, so if you want to run a local copy, you’ll need to download them separately.)

There is really no changes to what the code does. The changes are mostly structural. The single object with a bunch of function has been changed to have all its functions grouped into new child objects. For example all code that has to do with the Missiles is now in an object called MissileHandler.

I done this to isolate the various parts as much as possible. Hiding various variables and functions so they are not easily accessible from whole code base. When everything is available from any position, it is tempting to interlock various variables, collections and functions together in ways that ends up looking like a complete mess. An awful mess that will requires a whole lot of untangling every time one want to make a change.

The isolation into separate object also have the added bonus of allowing inheritance, allowing code to be shared. In my code the two new objects PlayerEntity and BoulderEntity both inherits shared features from object BlockEntity. Meaning that I can for example use the same logic to move both objects around the screen.

The Tests

The new objects also created a logical way of dividing up the tests. Each object have its own “specs” file with test code. And each function got its own “suit” within that file. You can check out the spec file for MissileHandler to see what I mean.

I try to keep the tests simple and test as little behavior as possible with each test. I’ll end up with a lot of code that way, but I like being able to see exactly which part of an object is incorrect.

What’s next?

Besides still wanting to complete the list of features I specified in previous post, I would like to add some graphics and more effects to the game. Making it look a bite more like a game.

It might take a while until next update though. Right now I feel heavily drawn towards my other interests.