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:
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);
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.