Jump to content

  • Log In with Google      Sign In   
  • Create Account


Test Driven Development.. Examples?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Telios   Members   -  Reputation: 398

Like
0Likes
Like

Posted 11 January 2013 - 11:54 AM

Hiya,

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
{
public:
   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, 11 January 2013 - 11:56 AM.


Sponsor:

#2 frob   Moderators   -  Reputation: 20238

Like
4Likes
Like

Posted 11 January 2013 - 12:03 PM

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, 11 January 2013 - 12:10 PM.

Check out my personal indie blog at bryanwagstaff.com.

#3 Glass_Knife   Moderators   -  Reputation: 4091

Like
3Likes
Like

Posted 11 January 2013 - 01:25 PM

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...
//psudocode
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.
I think, therefore I am. I think? - "George Carlin"
Indie Game Programming




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS