I am now XBox 360 bound :D. It was one hellish of an experience getting one (that, and an HDTV). I called around to at least six different GameStops and EBGames in the Portland area. Not a single one had a single 360 in stock (hell, at this point in time, I was willing to buy just a core system and buy the various pieces in the bundle even though I would be spending more money in the long run). At this point, I'm thinking that Microsoft must be _SOOOO_ rich that they don't even want my money in the first place. Luckily, the last GameStop I called said they didn't have any but they were sure some of the stores in Vancouver (the 'Couv as we yokels call it) did. The first GameStop I called in Vancouver had a couple of the Bundles, just what I was looking for! Yay!
So, off I go. I stop at the GameStop in da 'couv, pick up my 360 and then I'm on my way to Best Buy to pick up an HDTV (after all, isn't it sort of pointless to spend the cash on a 360 if you don't have an HDTV to run it on? (I mean, why push all those pixels and amazing graphics if you can't truly experience them, right?)). We (my wife and I) ended up buying a 27" slimfit so it would fit in our car and existing television cabinet at home (plus, anything larger than 27-29" is really too big for the size of room we have it in). I even found a great price on one that supported both 720p and 1080i so I don't have to worry about all that mumbo-jumbo (at least I think, but I'm sure there are others out there that could "educate" me on the situation and show that I still have a lot to worry about (like "native resolution/display", etc. but _whatever_)).
Now just to get the bad boy home. And that's when it starts. We get the tv out to the car and..... it doesn't fit. Boy am I feeling like a jack-arse at this point. So, we call up the good ol' father-in-law since he has a full size car. Luckily, he was footloose and could come help us out. So, we're sitting out in the parking lot with our tv sitting behind our car while he is on his way. Then it starts raining. GREAT. So, I rush back in and grab a cart, rush back out, put the tv on the cart, and haul it back inside. Whew! That was a close one.
My father-in-law then arrives on the scene. We go to put the tv in the trunk, doesn't fit. Crap! We go to put it in the back seat, doesn't fit. CRAP CRAP! Buuuutttt, it _almost_ fit in the back seat. With a bit of coaxing and box "reshaping" we were able to get it in the back seat. At this point, I'm utterly ecstatic since I'm close to getting my new toys home and I get to be in bless for an hour or so before some friends show up for dinner plans that we had made earlier.
I get home, take out the tv and go to place the tv in the entertainment center: doesn't fit! Crap, the opening for the tv is about two inches two small to accept the new television. Well, time to do some cabinet modding ::grins::. Since the entertainment center is one of those cheap Sauder-like cabinets, I have no qualms about doing some exploratory surgery on it. I go ahead and unscrew the top off and whack out _everything_ in the middle (the divider down the middle between the component shelves and the tv as well as all the shelves themselves). With how the tv is shaped, I can fit my components just behind the front of the tv and off to the side. Sweet! Everything fits now. On to the 360 :).
So, I take everything out, hook it all up and decide to clean up after myself since we have company coming over. After throwing all my trash away, I plug in the control and sit back on the couch (ready to have my socks knocked off). Then as soon as my first game boots up, DING DONG, guests are here. Damn! So close. We spent most of the evening with our friends so by the time they left, I was exhausted and had to go to bed in order to get some sleep for work today.
I can't tell you just how tempting it was to stay home from work today to give my 360 some much needed love. But seeing as my mommy didn't raise no fool, I know where my paycheck comes from (the thing that enabled me to get a 360 in the first place, I might add). So, here I am sitting at work doing "my thang" while my 360 sits at home gathering dust. Luckily I came into work quite early today so I can leave work quite early :). Then, it will be all-out 360 gaming bliss :D.
I suppose now that Rory has posted about it, the secret is out. Yes, I am _indeed_ a Crazy Man. This last Saturday, I was at Rory's most of the day shooting my part for a new video he is doing (I won't get into any more detail than that though, as my lips are sealed). However, what should really confuse people about this new "project", is the following video Rory has released on his blog: http://neopoleon.com/blog/posts/18742.aspx.
I'm guessing Rory just got a crash course in just how silly I can be since that scene was shot on the spot as I got into "costume". Here's where you all can feel sorry for my wife since this is how I just behave sometimes when I'm in my "silly moods" (which is more often than you might think).
Anyways, I can only imagine what y'all are going to think. All I will say is that I can't wait until the "new project" is officially released as I think y'all will enjoy it :).
P.S. This is also the reason (as well as another post coming up) that no progress was made on Tanks lately. More on that later.
I kind of touched on this issue in my last Tanks update. Thomas was nice enough to leave a comment and a follow up post that he made. I went to leave a comment on his blog in response to his post but "anonymous" comments aren't allowed and, frankly, I don't want to sign up for an iBlogger account simply so I can leave a comment. So, with that said, I'm just going to post my response here.
------
When writing unit tests, I no longer really think about methods. What I have started to think about is a behavior or responsibility of the class under test (which is _really_ done if you're doing TDD). If this test involves testing multiple methods so be it. Then if the behavior changes, you only have to change a small amount of tests.
I also believe that thinking about behavior when testing encourages developers to think about the "Single Responsibility Principle". If you're focusing on behavior and the test is hard to write, there is a good chance that the behavior of your class is too convoluted or complicated to test well. Or if the test becomes very long, it is likely that the responsibilities imposed on the class are too great.
In my opinion, developers need to get used to thinking about the "test matrix" for the class under test and focusing on code coverage. The number of "edge cases" can be minimized by using a Design By Contract approach to ensure the state of the class is always in an expected state. This way you don't have to have a separate test case for everything under the sun (fail fast, fail often). So, if I can get full coverage of a behavior by simpling expanding the scope of one test (like sending more commands/events through the system), than I will do that and get higher test coverage using a single test.
Of course you always have to be conscious of striking that balance between a test that gets a lot of code coverage done versus a test that is hard to read because it is too large and convoluted itself.
However, my opinion is still morphing on this subject the more unit testing I do. My only concrete rule of thumb is that if you start testing the abilities of the framework itself, you've dug too deep (like setting a property and asserting the value is what you expect it to be). A lot of the scenarios that test the behavior of the framework itself can be covered by "side effect" where other tests would fail if the framework every changes the way it behaves (but how likely is that?).
Anyone have any strong thoughts or opinions on the subject of unit testing granularity? When is it too granular, when is it not granular enough? Where do you draw the line?
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).
Late night inspiration! Sometimes I really love these kinds of moments. This one came to me as I was trying to get to sleep (and apparently my brain didn't want to let the problem go :)). One of the problems I discussed in an earlier update was that, for some reason, the Irrlicht .NET wrapper decided to implement all "interfaces" (ISceneManager, etc.) as classes, some of them not even containing default constructors. The heart burn this caused is that I'm not able to Mock and Unit Test my master TanksApplication class unless I go through all the trouble of taking all the Irrlicht "interfaces" and wrapping up my own interface-based facades around them. For this type of project, I didn't really want to go through all that hassle.
I guess something my brain saw during all my effort of getting Blender-exported .x files to work came to the forefront. Basically, I remember seeing when starting up the Irrlicht MeshViewer application that Irrlicht has actually implemented a "NullDriver" along with the other drivers (like Direct3D9, OpenGL, etc.). I tried it out in my application and it's pretty cool. It basically is a fully functional IrrlichtDevice but doesn't drive the graphics card. This will enable me to create a mock object that I can pass in and drive the TanksApplication with (by having the mock class be driven by the NullDriver and returning the actual Irrlicht classes rather than mocks themselves).
The "so-and-so" aspect of this is it's not necessarily a "true" mock object, but heck, it will work so that makes me happy right there. The other unfortunate side effect is that the unit tests in question will be tied to Irrlicht as well but that should be alright as making this application graphics-platform-independent is out of scope :).
I really get a kick out of some of these "a ha" moments :).
In other news, I have finished the unit tests around the GameEventParser class. All in all, I have increased code coverage from a dismal and depressing 15% to around 35% (still quite low, but a lot better than 15%). By the time I wrap the Console class up in unit tests (and the TanksApplication class after my late night realization above), I should be sitting above 50% which will put my mind more at ease with the state of the code base.
Now I'm back to trying to get to sleep (if my mind lets me), so I will chat with all y'all l8r (had to get at least one hackish expression in there ::grins::)
Peace out!
You know, it's interesting what kind of stuff you can find on the Microsoft Careers site (thanks for the link Joystiq). Direct Physics? Now that sounds interesting. If current market trends are any indication (like Ageia's PhysX Processor), this could be an interesting piece of news. Of course, with the fact that DirectPlay, DirectInput, DirectDraw, and others have all been deprecated or removed, it's interesting to think that Microsoft might be revamping DirectX by bringing in other technologies to it. With all the clues making it seem like Direct3D was the only viable DirectX-based technology left in the fray, I can't help but have my interest piqued by this job posting. And of course, with all the XNA Framework going on, I'm curious how this might fit into that as well. Regardless, I have a feeling that no matter what happens, we are going to hear exciting game development news out of the big M in the coming year or two.
|