Anti-Patterns for TDD

Stubled across this excellent article on anti-patterns, or code smells if you like, for test driven development. I actually find it quite good because I have often found it difficult in TDD to explain to people what to do. Perhaps it is easier to explain what not to do.... Anyways, I reckognize many of the smells from my early TDD experiences.

 

Playing with WatiN

I just discovered WatiN yesterday. I have been using Watir for some time now, but it has bugged me that the integration with Visual Studio was not very good. Especially the combination of using TestDriven.NET with Watir is not good. Hopefully WatiN will fix all that.

So in the process of trying to set up a controlled environment for WatiN to execute in, I stubled upon this great post by RobertMcLaws. When using Watir I have been irritated by the fact that the WebDev server within VS will start up on different ports whenever it bloody well feels like it! There is a rational explanation for the port change of course. But nevertheless it has required that I set up my IIS for using Watir. And that bugged me. Now things will probably get easier.

I will be posting more on WatiN as soon as I have played with it some more.

Kick Roberts story at DotNetKicks:

Infidelity and XNA

I'll start out by posting this unnessecary link to a good post on agile. Unnessecary becouase I got it from Joel, so evereybodys read it already. Nevertheless, I'll post it here for future reference. I think it is is a worthwile read.

Word around town is that I have been cheating on my blog. Unfaithful if you want. And that is all true. Yeah, I'll confess. I have started another Blog. In contrast to this blog, it is in Danish, and concentrated more on me and my personal life. "But you have been doing that here as well?". Yup. But that sort of takes the focus from this Blog. I would like to use this one more for tech related stuff... Work related. And not having to write a long post on what I am up to each time (see, you're doing it again!). And I think that is why I have a standstill in Blogging. Maybe.


All right: Game Development is the name of the game. Gosuman is up and running and I now get Game Development gigs. Cool. I will try to focus on doing the stuff with XNA, because XNA uses C# and that rocks. And because I can make stuff for my XBox 360. Right now I am learning and taking a course at ITU where we are making an FPS game with XNA. We want to focus on doing good AI, but since we're making it from the bottom up, we need to do all the plumbing as well. I have posted a screenshot. And maybe I will post a playable demo at some point. We'll see.

The spiritual machine

So, my XBox is bored. Or so it says anyway. Although it is temporally disturbed - still being on US time. So the blog dates don't quite match with reality here in Denmark.

Oblivion rocks. But I don't really feel that I am making much progress. There are so many things to do and see so I keep getting thrown off the main track. Closed my second Oblivion gate the other day and I am working hard to get all the reccomendations for getting further with the Mage Guild stuff.

Tomb Raider kicks ass well. I have always been a fan of the genre, and TR sets a very high mark. There are some lame things though - completed a motorcycle section which just seemed like a complete waste of time and energy. I can understand why they want to break the rhythm of the game to get a more cinematic experience. But that is not the way to do it.

Unit testing granularity

I read this post from Jason, who has recently taken up his game development project and related blogging. Keep up the good work dude! His post touched on granularity in unit testing, and this inspired me to blog.

When I started unit testing my testing was very structured so I had a test class per real class and a test method per method and per property. That worked well for a while, but for a large project I ran into the problem that my test methods became quite large because I tested the effect of the method in several different scenarios. My case was to try to optimize the test to test everything the method did in one place. I also methodically tested assumptions before doing the actual test - often testing that the same call did not return null before working with the actual result several times in a method. The result was often very long test methods for a single method - but at least I knew where that perticular test was and could track where the event went wrong.

After attending a course where we touched on the subject, I got a few points hammered down and I changed my strategy a bit and begun testing with a higher granularity. Now I have several test methods per method where every test test exactly one aspect of the method. I make sure that no tests are repeated, so if I have a test that test that under the conditions set up the method does not return null, I exepect the result not to be null in other tests. Furthermore I set up several distinct test classes for a class if there are different preconditions for the class. This is usually classes that hold some stae but are note yet ripe for being refactored into different state classes. The test class set up the right preconditions and then test the class under those conditions.

The end result is that I now have a significantly higher amount of test methods, and some of them correspond directly to methods, others correspond to different aspects of the functionality of the function. All test methods are also very short, having only one or two assert statements each. The effect is that though you have to look for the right method that fails, and you can have false positives in your failures, the code is much easier to read and understand. Furthermore when you change functionality for a method, I have to change only one or two test methods in order for it to work. Before I had to change several places in a single test method that could be hard to find, and because I was "methodical" enough to test my preconditions, a change could very well mean changes to several other test methods as well.

So my take on granularity is to keep it high. Make small methods that test one aspect of one method, and one thing only. Name the method so you know what it tests. When testing complex scenarios, set things up as preconditions in a sepereate class, write a single test that sees that the preconditions are met, and then assume that they are met in the oher test methods.

1..2..3.. Launch

So it is official. The first game created by Gosuman Games is live and vital. It is a game made for Netposten and is a simple stock guessing web-based game. I am actually quite pleased with how the game turned out, and of course getting to get payed to write a game. That, in itself, is a first for me. So while it is not an idea of my own, it is there and live. Check it out, if you read danish that is, otherwise you are USC for now. They have great prizes as well, there is a chance to win an iPod... Not bad for a game that only runs for a week at a time!

Of course it brings the nag of not completing my first independant production to mind... But my calendar for may looks like it might give some opportunities.

My project at ITU is nearing completion. We had a great meeting with our tutor today, she confirmed that we were on the right track. There is still some writing to do, and a lot of restructuring, but I think we are in good time. We originally had to hand it in next friday - but guess what. Steve Ballmer is coming to visit ITU, so we get a few days extra time to hand it in. Guess the security surrounding the handing in of projects is too much to handle when combined with Steve-O. :)

Lastly, i read newest The Escapist mag today. Mostly by accident, I had stumbled on it before where it didn't pique my interest. But this time I found myself suddenly reading the whole issue. And enjoying it too. So, maybe I'll become a regular reader.

OMG its that time already

Wow... Time has been flying by. Last post Feb 22. Hmm... I have been doing a lot of stuff. Working mostly. The game I have made for Netposten is about to launch, I have been doing some work on an ASP.NET/Sitecore thins for AlphaSolutions and some random stuff... And then I have my project on ITU that is nearing completion. It is to be handed in next friday - so I just have to overcome my writers block. But when it is done I will start feeling good about things again. This is just one of those times when a lot of different things have to be wrapped op - preferably all at the same time.

C# Edge

Just discovered that my good friend Troels has a Blog too called C# Edge. He is doing some amazing AJAX stuff with his OutPost module. Today I just saw that he got listed in Daniel Ziess' great AJAX comparison chart.

I, frankly, have to learn that stuff very soon. I am doing a game for a comapny called Netposten right now, pure ASP.NET, and it could surely use some snazzy AJAX features.

Third party product testing

Seems like it wasn't just a bad brainwave I had when I posted about testing 3rd party libraries. James Greening did a post on this as well. Saves me the trouble of elaborating. ;-)

Exam. Done!

So it is finally over. I had my exam yesterday morning. It went well. My grade was 10 (on a special danish scale to 13). And I am satisfied with that. Now I can practice relaxing. Some.

I am picking up my laptop that has been broken since monday. I had actually managed to break the motherboard (and the screen), how I did that I dont know. But they replaced both. Price: 3900 kr. Ouch. I could buy a new desktop for that money. Happily I aint paying. But I know now to be very careful. It is the first time in my 5 years of using a laptop only that I have broken one down. It is usually "only" the harddisk that breaks down. Which is actually worse!

This weekend we are going to our house in the country. I will be coding on a job that is up for first test monday, and Kat will be watching the royal baptism. All by the roaring fireplace. Can't get much better than that I assure you. It has been snowing heavily in denmark during the week, so it will be fantastic up there. Watch out for pics next week.

The joys of studying

I am currently studying for dear life for my Advanced OO Programming exam in two days. I had forgotten how much energy it takes learning concentrated, especially when you have to learn stuff that you are not going to use much after the exam. Admitted, there are great stuff in there like Design Patterns, Refactoring and so on that I will use, but also other things that are not pressing in my current line of work.

I just want to get it over with now. I feel ready enough. So bring it on.

Yesterday my laptop broke down. Really. I think it is related to the power supply, cause the thing is positively dead. Hopefully I will get it back by friday. Fortunately the hard drive was intact. That was my first concern. So I have my data. Especially my notes for the exam! But I feel so naked without my laptop...

The last thing. Congrats to my girlfriend. Today it is her 28th birthday. Hooray!

Good fun

The best WTF moments of 2005. I especally loved this comment:

A Whole Bunch of People Game Themselves to Death

The weird thing here isn't that people are dying while playing videogames. It's that we've already become so jaded about it that it's stopped being newsworthy when it happens. A WoW player starving to death is like the sun coming up in the morning. You can't throw a rock in Korea without hitting a cybercafe full of dead WoW players.

Planning you refactorings

So, it happened again. It is one of my starting game projects, and i just had to make a small refactor to extract a class. And before I knew it I was in hell. Creating more supporting classes, interfaces and implementing them, what have you. I was lucky this time, it was a "small" fix taking only an hour of concentrated work mostly fixing compiler bugs to see what I missed. But it could have been done better if I had been taking Martin Fowlers words seriously and done it in planned controlled steps.

The great part of this story is that I get to post my motto, which I haven't had the opportunity to do before!

It is not learning from you mistakes that is hard. It is applying that knowledge so that you don't make the mistake again.

Someday I'll learn and not end up doing what I did in december to the d20Sharp project that right now is in a non-compilable state somwhere in code-growing-cold limbo. I'll have to fix it soon.

The joys of old school windows programming

Yesterday I had this long debugging session that made me remember how much I love doing TDD. I have written about that C++ project I am working on - it was in that project where I had an issue with focusing that just didn't work properly. So I had to follow the windows messages around. Trace logging and what have you. I HATE THAT. I finally cracked the problem, but boy was I used up afterwards. The project is soon over and then I can go back to TDD C# programming.

Now there is probably some of you hard core C++ programmers that are saying: But why don't you do TDD with C++. You can do that! CppUnit! I have only the standard lame excuse: I didn't think there was time enough for me to learn how to use CppUnit on such a short, and probably one-time, project. I am not using C++ every day you know!. Well, the time spent debugging could have justified that. Allthough I had probably spent at least that time figuring out how the hell to test the issues I was having. And that brings me to what I think is one of the core issues for people learning TDD. Learning HOW to test things..

I read another blog (will try to find the link, think it was one of the FitNesse guys), that talked about "stupid test". Test that test for the obvious, which you usually have in abundance. The problem with these tests are that they do not test the object as it it supposed to be used, but only test things in thought out controlled scenarios. And when you get it out in the real project things fail anyway.

There is something right in that point. The first thing you do when learning TDD is to write black box testing of one class. A standard Modus Operandum that is easy to teach people is: Write at least one test for each contructor/method/property in the class. In my opinion that only adds real value when you test fringe cases. Those are the tests that help you aviod the hard-to-track bugs.

The next thing you do is design you objects properly for testing. That usually means being more aware of the Single Responsibility Principle (pdf) and doing
Dependency Injection. This opens a whole new set of issues where you mock the objects to be injected in order to test the object. One of the pitfalls I see there is when you incect objects that doesn't behave badly. Especially if the object you are mocking out is going to be a third party object out of your control that can (and then will) fail when doing complex real-world things, or when you want your injected objects to be subclasses - probably by others. Then you will probably see your object fail in new strange and wonderful ways if you don't test for it.

I have no solutions for this issue. But I think there are points to be aware of.

• Put you effort on your objects into testing border-line cases.


• Make your "controlled" testing environment as "real" as possible.


• Make tests where your injected objects behave badly.


• Do test for your third party components in the ways that you want to use them.

Hmmm... The last point was actually one that got me thinking. Great when you dig up ideas by blogging related ideas. I'll probably be diggin into that point more later.

Now. CYA. Have a badly behaving project to see to.

Another day. Another Acievement.

I can't stress enough how addictive it is with the achievement system on the XBox 360. Racking up gamer points that earn you bragging rights towards your friends is just so immensely cool. I really like looking at what my friends have been doing on their box when we do not have time to play online against eachother. As you may have noticed, I found out yesterday that you can get your gamer card to put live on your homepage. Neat O! So now you can all see - even without a 360 - and maybe you will get annoyed enough to go buy one, if they ever get widely available in stores, that is, and add me (Fehaare) to your friends list so we can compete.

I do miss some things on the box though though: A list of your friends ranked by gamer points and notifications when one of your friends beat your high score in a game. That would be good additions.

Sometimes it can be HARD to get things done

Especially when you have a lazy cat lounging on top of your computer... Other than that I have started the new year pretty well. Happy new year to all you frequent readers BTW. Now it is officially 2006, so the company can finally get started. Tomorrow I am going to speak with my lawyer and my bank too se how we are going to do things so I can get some starting captial - preferably without it costing me obscene amounts of interests! Not that I desperately need money in the company. I haven't got many need to have things that I well, NEED to have right now. So better save what I can for a the rainy days. My first jobs are going smoothly and more are getting added to the list, small ones, but still they mean money.
My business plan is also getting there. Especially I am working on a running plan where I can track my progress according to the goals I have set for the business in 2006. I think it is very imortant to have measurable goals, and be able to measure on them constantly. If you don't know where you stand, you have no idea where to put your efforts. Especially because I could easily get lost in just working my butt off for a lot of people and not getting any real work done on the games. And that would not be fruitful. One of my goals is that 5% of the income for 2006 have to come from games or game-related jobs. It is not a lot, but I expect it to be hard to get into the market, so I am content if it lands there.
Lastly, take a look at this great link that I shamelessly lifted from James Shores blog: Seven habits of highly eficient programmers. I think it is a good post that it is hard not to agree with. Maybe it doesn't bring many new things to the table, but it definately sums up some good practices.