Geeks With Blogs

News

Series

Add to Technorati Favorites


An Archived Managed World This blog has moved to http://www.managed-world.com/blog

[Crosspost from Managed World]

Great. If it wasn't bad enough being sick still, my internet connection just had to be down all evening. Luckily, it _just_ came back up so I can actually post this update. So let's discuss the progress on Tanks, shall we?

Most of my "free time" I've had lately (which hasn't been much with me being sick (since my body proclaimed several hours at a time to be "nappy time")) I've spent writing the unit tests around the last couple of classes I ported over from my previous project. The process has made me appreciate the work Microsoft has put into Visual Studio 2005. Having the integrated Code Coverage reports is pretty nice. I know you can get that with NCover/NCoverExplorer, it's just nice to have it "out of the box". You add to that all the amazing work that Jamie Cansdale has put into the TestDriven.NET add-in and it makes for a wonderful environment to be writing unit tests in :). I don't know why, but I get a certain thrill out of writing some unit tests and then seeing my code coverage increase.

The ConsoleModel class is finally wrapped up in unit tests and tucked in to bed for the night. What kind of surprised me is that by writing the unit tests I wanted to write against the ConsoleModel class, it just so happened that I got full coverage on my ConsoleEntryLine class as well (which is used by the ConsoleModel class). Killing two birds with one stone is nice sometimes :). For my Tanks.exe, I'm up to 67% test coverage. That number is a little misleading though as I have all my unit tests within the executable itself. If I don't count my "Test" namespace and only count the core "ManagedWorld.Tanks" namespace, I'm actually sitting around 51% test coverage (right around where I thought I would be at this time).

The problem I have right now is the rest of the code currently in the code base (or about to join the code base), is all device specific around the IrrlichtDevice. I don't really want to unit test down to that level as the ROI would start to decline dramatically with the time I would have to invest simply writing the unit tests. However, that doesn't mean I don't want it tested. I'm thinking that sooner or later I'll work on introducing a script-based testing framework for the application. Then I'll write a harness that can be run from NUnit. My hope currently is that the NullDriver for the IrrlichtDevice will still be fully functional under the hood but simply won't be driving the graphics card. If that is the case, then I should be able to write this script-based testing framework (not that it won't be without it's hardships). Then I can use the scripts as more of an "acceptance tests" system that will help me test from the UI level. Of course, my hope is that if I can do that via the NUnit custom harness, then it will be able to be reflected in my code coverage reports alongside of all my unit tests. I still feel like this is quite a ways into the future from now though (meaning, I won't worry about it until I cross that bridge since there's no shortage of tasks to be done in the meantime).

I have a confession though: I'm trying to not get too granular with my unit testing. I know some people have strong opinions on what level of granularity to unit test. For me, it just seems "wrong" to have one separate unit test per method in a class. I can't really put my thumb on why I feel that way yet. But having one test fixture per class, and one unit test per method (or I've seen even smaller in the past (meaning multiple unit tests per method)) just seems like it is missing the boat. By the time you get this detailed, it seems like you begin testing the functionality of the .NET Framework rather than focusing on the behavior of your class under test.

I've even started to think that maybe focusing on testing one class at a time might be too granular as well, but the jury's still out on that one :). If you can test all the nooks and crannies of your class at the module level, than why not do so as the unit tests can become much more clear to read (since they start asserting behaviors of the module as a whole). Enough of my ruminations for one post. I'm still largely a unit testing newbie, so I won't bore you with my not-yet-mature stream of consciousness.

So, what next? I believe I'll crank out the ConsoleController and test that. Once that is finished, it is on to the ConsoleView. I'm still not sure how I'm going to test that (if I'm going to test it at all). Once that is done, however, the Model/View/Controller for the Console will be finished and will be ready to integrate into the game. Maybe then I can "call it good" for this stage of the game and get started on replacing those articles that I never finished a LONG TIME AGO (although _not_ in a galaxy far far away (contrary to popular belief)).

Catch you on the flip side, space men :P. (I was going to say "filthy pig dogs" but I thought that some of you might get offended if you don't know where it comes from).

Posted on Wednesday, May 3, 2006 6:57 AM Game Development | Back to top


Comments on this post: Tanks - Update 5

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Jason Olson | Powered by: GeeksWithBlogs.net