Comments on: Stepping Through the Looking Glass: Test-Driven Game Development (Part 1)

By: Chad Austin

Chad Austin — Wed, 27 Apr 2005 14:33:53 +0000

Test Driven Development: First Impressions

By: Fosta's Blog

Fosta's Blog — Mon, 07 Mar 2005 20:19:10 +0000

Test Driven Development

By: Radium Software Development

Radium Software Development — Mon, 07 Mar 2005 16:58:52 +0000

Test Driven Development

By: The Shoes of the Fisherman's Wife Are Some Jive-Ass Slippers

The Shoes of the Fisherman's Wife Are Some Jive-Ass Slippers — Mon, 07 Mar 2005 16:57:01 +0000

More On Test Driven Development

By: IndieGameDev

IndieGameDev — Sat, 05 Mar 2005 16:08:21 +0000

Games from Within Games from Within is a weblog written by Noel Llopis, who has a pretty impressive game d...

By: Baraclese

Baraclese — Thu, 03 Mar 2005 00:44:37 +0000

Okay, I just worked a few hours on setting up a unit test suite for my project. Most of that time was spent in my SConstruct/script files, I pretty much had to throw out all of my old code to support more than one executable, to get the build directories right and handle different environments more flexibly, it’s much better now. I use the boost testing framework cause I love boost.

Guess what?! I discovered a bug in my first test! I was alittle puzzled at first because I thought “it can’t be! it works fine in the game!”. I made an unconscious assumption about a container never being empty, dereferencing the iterator in a tiny hidden loop. BOOM! I stepped in with gdb, found the function that was called and repaired the sourcecode.

Am I convinced? Hell yes, it’s fun too.

By: Paul Higinbotham

Paul Higinbotham — Tue, 01 Mar 2005 16:35:30 +0000

Noel, I didn’t mean to imply that I thought TDD was not a good method. I think it is a great way to create and test public methods and functions. Forcing developers to run/pass unit-tests before checking in code is a bit of a pain, but well worth the effort based on my limited experience.

The drawback I was talking about earlier is really a more general problem and not related directly to TDD. I guess it is more related to agile programming. I really like the idea of constantly refactoring code/classes/interfaces and corresponding unit-tests. I rarely get all of my class methods right the first time I create them. It is not until I start using the class do I realize the best methods I need and how they should work. Being able to refactor is crucial to getting to the right design and implementation.

But most projects I’ve been on tend to resist any changes to “public” code that could affect documents, developers, or testers. Instead developers are encouraged to work-around any deficiencies. Work-arounds can be Ok but they can also lead to hacky bloated code, duplicate functionality, and performance problems. The longer the work-arounds are in the more likely they become a permanent part of the code base. Changes to the code (and unit-tests) sometimes finally occur at the eleventh hour when ship stopping functional and performance problems become apparent.

This is really a management problem and not a TDD problem. I just brought this up because in my last project we used unit-tests to not only drive code development but to also document and specify public interfaces/classes. Later in the project during coding that actually used the public classes it was almost impossible to get a method changed or added. This in part caused severe end-game problems and a seven month slip in ship date.

By: Julien Koenen

Julien Koenen — Mon, 28 Feb 2005 09:07:20 +0000

There is a short summary (in german) here: http://igda.dimajix.net/fileadmin/ressources/report-03/07_roeken_summary.pdf

By: Noel Llopis

Noel Llopis — Sun, 27 Feb 2005 17:17:36 +0000

Chris: Good idea about the DLLs! Using DLLs might make it easier to run all the tests. I hadn’t considered before because most of my work had been with static libs, but it’s definitely worth looking into.

Do you have a link to Röken’s presentation? I Googled for it but nothing came up. I’d love to find out more about what they’re doing.

By: Noel Llopis

Noel Llopis — Sun, 27 Feb 2005 17:12:35 +0000

Robert and Paul: Build times can be an issue if it’s not done correctly. I’ll definitely talk about that in the third part of the article. For now I’ll just say that using TDD gave me the fastest iteration times I’ve ever seen in my life because you’re working with one particular library and not with a whole bunch of code at once.

Each unit test should really be blazingly fast. Probably in the order of a microsecond. You should be able to run 100,000 of those in one second, so that shouldn’t be an issue. Remember, these are *unit tests*, so they work directly on one class, not on the whole program.

What do you see at some of the drawbacks of TDD? There’s the extra code, but frankly, I see that more of an advantage than a disadvantage.