Test Driven Development: Prologue.

I’m putting down, for the record, that I’m going to endeavour to do more testing in my software. I plan to do this by means of Test Driven Development. While I plan to do as much work as possible in Xcode probably using GHUnit or OCUnit, visual studio is proving inescapable so I’ll probably be using NUnit as well.

What I already know.

I went for an interview for an industrial placement at a software company that uses Extreme Erogramming with TDD for all of their software. Now, I’m a big fan of XP and this has proven hugely successful for this company so I paid attention to their processes.

  1. Write the test. Make sure you give it a name that describes what the test is for.
  2. Fail the test. This was really important, especially as the application starts to grow, because new tests won’t always fail, but they should. If you skip this step you can end up wasting a lot of time trying to fix a problem that isn’t there.
  3. Get the test to pass as quickly as possible. This is also very important because it stops you spending hours trying to implement the most ideal solution and losing scope of what you’re trying to do. Literally just throw in whatever you can to get that test to pass.
  4. Refactor. Make it look nice, now is that time to maybe think about the ideal implementation, but not too much.

This approach gets a lot of criticism from people saying that it promotes bad design, or poorly written code. But the idea behind TDD is that you’re focussing on a single problem at a time. So when you start, yeah you have a bunch of really inflexible code and virtually no design in place. But as the number of tests grows and likewise the application, better design falls right into place and you end up with a very robust piece of software.

Anyway, I’ll see how I get on. It may be a bit naive of me to just be saying All my products will be TDD from now on┬ábut I’m going to give it a go and see how far I get.

Group Work

This post may come across as whiny, it’s really not meant to be so, I’m just trying to document the entire experience so that the lessons learned are more clear.

This semester I had the pleasure of a group assignment. This particular module awarded a great deal of freedom in the assignment and looked to be very very fun. I was excited about this class.

I was given some advice earlier in the year on group work, that was a few items that are roughly as follows.
1. Find a group of good people, not your friends.
2. You’re going to get roped into being the team leader sooner or later.
3. Don’t forget that others struggle with this stuff more than you do.

The assignment can be summed up as this; as a group make a game engine and use it to make four different genres of game to demonstrate the engine. Awesome.

Firstly there was the division of work.
We talked and talked about what kind of games we wanted to make in the hopes that it would give us an idea of what types of engine components we needed. 2 weeks of these talks got us no where, so it came down to me to make the decision for everyone.
So I decreed: “I want AI, you do physics, you do graphics.”
“But I don’t want graphics.”
“Fine I’ll do graphics. You do physics”
A little time passed and I actually wrote a working tile engine for the game before.
“I can’t do physics I want something else, but graphics is too easy.”
and so on.

The end resulted in me on physics, him on AI and him on Graphics. But surely the more astute of you have noticed that me, him and him only amount to three, and I mentioned four before.
That’s because another ‘friend’ found himself without a group. So me being the charitable person I am had suggested that we wouldn’t have a problem with him joining our group. He was a sharp guy, if a little unreliable, very unreliable… What the hell was I thinking? I regretted this decision the moment I spoke up. Having this guy in our group could only mean disaster…

So then, what should the new guy do? Sound? No too easy. Physics? No too easy (thanks). I want to do a lighting engine. Great, it wasn’t a crucial component to the engine and if he finished, it would be a cool effect.

The weeks went on and our graphics were finished in an instant, well done you. We had a tile engine and a screen manger and some basic artwork. Meanwhile I’d created some of the framework of my physics and got a particle system working pretty quickly.
More weeks rolled by and I worked and tuned my physics and started working on collisions and all that goes with it. All was going relatively well, except that guy number 4 vanished. He stopped attending classes, didn’t so any work, wouldn’t answer messages, nothing. So we counted him as lost and resumed as a three piece. Or so I thought.

Week 10 rolled up, two weeks to go before christmas break, 4 weeks before hand in. I proudly finished my physics engine and started working on my physics based game. The graphics stuff still lay there, unchanged, no sign of AI.
Week 12 came around, it was christmas break and I’d finished my game, I had no more work to do…
First week of christmas break rolled by and there were quite a few premonitions of work but none actually appeared. Second week is when suddenly my team burst into a flurry of activity. Guy number four appeared out of no where with a complete lighting system, which I greedily incorporated into my game, and then he vanished again. The graphics stayed the same and still no sign of AI but I was assured that the work was being done.

3 days before hand in work started to appear, first part of a graphics game and some additional features, then some AI that didn’t work, but would eventually. Oh goodie. I was bombarded with questions and problems and ideas, none of which I had any time for but couldn’t ignore because my grade was on the line.

I’m happy to report that we made hand in with a working game engine, 4 game demos and a report. It all looks like it was put together by drunken monkeys. I’ve asked for the project to be graded on an individual basis in hope that I can save some of my marks but we’ll have to wait and see. The entire thing was very frustrating for me and while I did my best to be Mr. Optimism and Support I came very close to negotiating a solo contract with the module leader.

In the end our demo received praise, the tutor was impressed by the number of features it engine included and said it was a good project. So alls well that ends well I guess, hopefully we’ve come away with good marks despite the issues and hopefully we all learned something about working as a team.

What did I learn?
Take advice from academics when it’s given to you. They’ve seen countless students fail and succeed and thus, they’re in the best position to advise you on such matters.

Friends usually don’t make good co-workers.

As flattering as it is to have people leaning on you for support, it doesn’t help you stand up straight.

Never underestimate the amount of work a student can get done in one night.