Ok, have you ever been in this situation? You are creating a game or application and all goes well. Still, testing new additions to the program takes more and more time, as you have to spend time to get to the new part or feature, and every little thing you change needs to be retested, so you re-compile, try and test, change, re-compile, etc. This gets more and more time consuming as your program grows. Wouldn’t it be great if you could test your new object type or changes without having to re-compile your game or application every single time? You can! With Unit Testing and TTD (Test Driven Development).
Before I go on: here is a great introduction to unit testing and test driven development in relation to games. Read it and then come back…
Back? Ok, let’s continue and let’s see how we can do all of this in Blitzmax.
First up we will need a framework to perform tests in. Luckily Brucey has something for everybody, so go get the bah.maxunit mod from here. Brucey also has a nice WIKI entry for this module, which gives you an introduction on how to use the unit test module.
There is one thing however to point out and this is what TTD comes down to, and what that WIKI entry does not do: In TTD you write the tests first, then you write the code to make the test pass. In his example Brucey writes code he knows is wrong and then writes a test for it. Using TTD you would write the test first, see it fail, and then you add code to your object to make the test pass.
This appears to be more work than just writing the program straight away, as you used to do. At first this may be the case to get you up and running but as more and more code is added to the project you will see the benefit.
There is one interesting problem though. Sometimes your object-to-be-tested needs image files or sounds, or other objects from your project to be constructed, but you don’t need those to test the code inside your object. This is where mocks come into play. A mock is an extended version of your test object which uses a different constructor or overridden methods to get around this problem.
Think of the test code as a bare-bones version of your application or game which is only used to run and confirm that your code works as intended. As you only run the code you want to test, you don’t need graphics modes and all that other stuff your game/application needs to run.
It’s a change of habit, a different mindset even, and not in the spirit of hobby and guerrilla coding but it works for me!
It might also be the solution to your development woes and the boost you need to get over that threshold to finally finish that project instead of being caught in endless bug hunting sessions. I will make some example posts if I get enough comments on this blog entry.