Unit Tests Con't

posted in I am a duck
Published December 12, 2006
Advertisement
Quick post to answer Jason's questions.

1. Do tests look for exceptional cases or functionality of the class?

Unit tests are meant to tests the core functionality of the object. I go by the mantra of writing tests to cover parameters going in and return values going out. By that I mean for every parameter going in I'm testing a valid value and an invalid value. I'll also make sure I have tests that cover all valid return values. Should end up being around 1-5 tests per method depending on the number of parameters and return values.

Things like corner test cases would be left for a formal test pass if you have a test team. Like most of us you probably don't :). In that case I do try and add such cases to my unit tests if they pop into my mind or when I come across a related bug. Generally any time I find a bug in a class I try to figure out why my unit tests didn't catch it and then write a new test that will catch it. Once again this may seem useless since I've already found the bug but refactoring can bring bugs back from the dead. I want a test there to catch it if it does.

2. Do you create tests for every method on very class?

Yes. This is the essence of unit testing. The goal is to have a list of objects that you can really trust. The only way to do that is to test everything. This can be a daunting task with older code so I suggest starting out writing unit tests whenever you create a new class and then slowly go back and write tests for your old code. Odds are you are never going to get 100% coverage on your old code but you'll find that a lot of old code disappears anyways.

If you have classes that have 100+ methods then most likely it's time to do some refactoring. One of the things about OO design is that it's easy to end up with bloated base classes that need to be split out. It's an evil that hits us all. I target a major refactoring pass after every major project to see what's worked and what hasn't. This refactoring is the very reason why you want the unit tests around. Saves you a lot of pain.
Previous Entry Not fun but good.
Next Entry Unit Tests: part 3
0 likes 1 comments

Comments

Jason Z
Mike - thanks for the replies. My problem is that my huge base class is a very logical progression from a couple of years of development. The reason that it has so many methods is that it represents a 3D entity in a software system that is intended to render 3D entities - there really isn't a logical reason to break up the functionality (in my mind anyways).

I still like the idea of unit tests though. Regardless of if the methods are contained within 10 classes or 1 class I still have to write the tests for 100 methods, so they are still a valid task for me to do. Do you have any further examples or maybe a reference for me to get started? I am just having a hard time figuring out how to test a method where you set an entity's position - it doesn't immediately present itself.

Like you said, I will start with the new functionality and continue on with the other classes later on. Thanks again for the information!
December 13, 2006 05:02 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement