• entries
    205
  • comments
    228
  • views
    112807

Unit Tests: part 3

Sign in to follow this  
Mike Bossy

74 views

A couple more answers for Jason.

First off big base classes:

One reason why you might not want big bases classes is if you want to replace some of it. You could imagine that you might want to change graphics APIs at sometime in the future. If you have all of your graphics stuff encapsulated into a class that your mondo object points to then you can easily plug a new class in later that maybe uses GL instead of DX. This wouldn't have any affect on the rest of your object. Once again its just a way to insulate yourself from change affecting everything.

Example test for setting object position:

This scenario is fairly easy. Going on the assumption that you have a method on your object to set it's XYZ co-ords all you have to do is call that method and then verify that your co-ords are updated. It might look like this:


TEST(SetCoords)
{
float X, Y, Z;

// Create the object
CGameObject *Temp = new CGameObject();

// Set its position
Temp->SetXYZ(10.0, 10.0, 10.0);

// Get the current position
Temp->GetXYZ(&X, &Y, &Z);

// Check our values
CHECK(X == 10.0);
CHECK(Y == 10.0);
CHECK(Z == 10.0);

delete Temp;
}




You might be making it more complex by thinking about testing things visually, like "did it draw in the right position?" This is not what unit tests are for. This unit test will test the SetXYZ method only. Testing that your rendering functions use that value properly is a totally different test.

There is a bunch of stuff on the net around unit testing if you google it.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now