• Advertisement
Sign in to follow this  

Test Driven Development.. Examples?

This topic is 1837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


I recently read about Test Driven Development, and I thought I'd give it a try. I've had some trouble finding meaningful test examples, and I was hoping someone could point me in the right direction with two simple interfaces from my current project.
// This interface is used to convert string identifiers to faster string IDs.
typedef unsigned int StringId;

StringId hashString(const std::string& str);
I should probably create two tests for this using known string IDs - perhaps one for an empty string, and one non-zero length known value?
// This interface is used to load game assets asynchronously.
class AssetLoadJob;

class AssetLoadThread : private boost::noncopyable
   void submitJob(AssetLoadJob *loadJob);
I'm not sure about this one. It might be an idea to use three tests - a valid job, an invalid job and a null pointer (which should trigger an assertion)?

Hopefully if I can get the feel for it using simpler interfaces, I'll have a chance of writing decent tests for the more complex ones. I know it takes enough time to write _your own_ tests, so any insight here would really be appreciated :)

Many thanks. Edited by Telios

Share this post

Link to post
Share on other sites

The ever popular TDD Tetris Walk-through .


Note that in corporate game development environments, most of the one-shot, non-maintained code is such that TDD doesn't make economic sense.  The engine might make sense, game specific logic usually not as much.


As a hobby developer with no QA support, TDD makes much more sense.

Edited by frob

Share this post

Link to post
Share on other sites
There is a big difference between writing unit tests that test code that has already been written, and test driving your code by only writing code after you have failing tests. One of the problems I had when I first started trying to teach myself TDD was that I would start by writing the class, and then figure out how to test it.

But this is backwards. The problem is, when you have never done any unit tests, and you don't know the API very well, it is hard to just write the tests first, because you have no idea what a good test should look like. You've got no experience.

In the tutorial presented, you test drive the code. There is an initial test checking if the board is empty. It took me a long time to realize that you only write the code you need, breaking all the rules. For example, if I am making a list of some kind (because I need one for the code, not because I've already decided on an architecture), it might go like this...
testNewListIsEmpty() {
   List list = new List();
   assertTrue( list.isEmpty() );
   assertEquals( 0, list.size() );

To make this work, I would code a class as follows:
class List {

   public boolean isEmpty() {
      return true;

   public int size() {
      return 0;

I can't speak for anyone else, but this was the hardest part for TDD for me. The above code doesn't do anything. It doesn't store any files, and yet, it is the simplest code needed to make the tests pass. I felt really silly writing code like this, and in fact, it is silly, but only for this example.

Learning to take small steps only adding what you need may seems strange, but when you begin to tackle a problem you have NO IDEA how to solve, you'll be surprised at the the clean, easy-to-use code that can come out of this.

So do your best, and, just for fun, instead of deciding you need interfaces, just write ONLY what you need.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement